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Wireshark 是 当前 最 流行 的 网 络 包 分 析 工具 。 它 上 手 简单 ， 无 需 培 训 就 可 入 门 。 很 多 棘手 的 
网 络 问题 遇 到 Wireshark 都 能 迎刃而解 。 

本 书 挑选 的 网 络 包 来 自 真 实 场景 ， 经 典 且 接地 气 。 讲 解 时 采用 了 生活 化 的 语言 ， 力 求 通俗 
易 懂 ， 以 使 读者 在 轻松 阅读 的 过 程 中 ， 既 可 以 学 到 实用 的 网 络 知识 ， 又 能 形成 解决 问题 的 思 
路 。 

与 大 多 网 络 图 书 的 课堂 式 体验 不 同 ， 阅 读本 书 的 感觉 更 像 在 听 技 术 圈 的 朋友 分 诗经 验 ， 除 
了 知识 ， 还 有 心情 和 想法 。 本 书 的 覆盖 范围 从 日 常 使 用 的 手机 App， 到 企业 级 的 数据 中 心 ， 从 
对 付 运 营 商 的 网 络 劫持 ， 到 开发 自己 的 分 析 工 具 ， 不 一 而 足 。 无 论 你 是 系统 管理 员 、 实 施工 程 
师 、 技 术 支 持 、 网 管 、 培 训 教 师 ， 还 是 开发 和 测试 人 员 ， 都 适合 阅读 本 书 。 





















































关于 作者 


林 沛 满 ，2005 年 毕业 于 上 海 交 通 大 学 ， 现 任 EMC 网 络 存 储 部 门 的 主 
任 工程 师 。 多 年 来 为 多 个 产品 团队 提供 过 技术 咨询 ， 范 围 包 括 网 络 、 操 
作 系 统 、 文 件 系 统 和 域 等 ， 这 就 是 本 书 所 涵盖 的 协议 如 此 五 花 八 门 的 原 
因 。 每 年 临近 加 薪 的 日 子 ， 他 也 会 组 织 一 些 技 术 培 训 来 提醒 上 司 ， 本 书 
的 部 分 内 容 就 来 自 这 些 培 训 资料 。 

平时 他 也 写 一 些 技术 博客 ， 你 或 许 还 
社区 看 到 它们 ， 本 书 也 有 少数 内 容 来 自 这 
络 分 析 就 这 么 简单 》 的 作者 。 

当 林 先生 不 在 工作 时 ， 大 部 分 时 间 都 花 在 了 园艺 花 开 上 ， 尤 其 是 欧 
浏 月 地， 





能 在 IT168 或 者 ChinaUnix 技 术 
些 博 客 。 他 也 是 《Wireshark 网 
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我 那些 没有 技术 背景 的 亲友 只 能 读 懂 这 一 部 分 ， 所 以 要 尺 量 写 得 好 
i 
分 析 网 络 包 占用 了 很 多 本 应 该 和 家 人 在 一 起 的 时 光 ， 因 此 要 特别 感 
谢 他 们 的 理解 和 支持 。 我 妻子 在 每 天 忙碌 的 工作 之 余 ， 还 要 弥补 我 的 那 
份 杀 子 时 间 ， 让 小 满 享 受到 完美 的 色情 。 她 也 是 第 一 个 审核 书稿 的 人 ， 
包括 文字 和 技术 两 方面 ,“ 贰 内 助 ” 一 词 已 经 不 足以 形容 她 的 贡献 了 。 我 
父母 分 担 了 很 多 家 庭 区 动 ， 人 否则 花园 里 早 就 杂 草 丛生 。 他 们 可 能 人 至今 还 
以 为 我 坐 在 电脑 面前 就 是 在 赶 稿子 。 

技术 图 的 很 多 朋友 帮忙 检阅 了 本 书 部 分 章节， 为 我 严 把 撤 术 关 。 请 
给 我 一 次 招待 你 们 吃 大 餐 的 机 会 。 

我 的 老板 从 没有 提出 过 KPI 上 的 要 求 ， 因 此 我 才 有 这 么 多 时 间 研 究 
工作 之 外 的 技术 问题 。 

此 外 还 要 感谢 很 多 读者 长 期 的 或 励 ， 请 总 我 无 法 一 一 列举 你 们 的 名 
字 。 要 不 是 你 们 隔 段 时 间 就 催 一 下 ， 以 我 的 拖延 症 不 知 着 何 日 才能 写 
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Wireshark 己 经 用 不 看 我 来 做 广告 了 ， 它 早已 被 多 家 权威 机 构 评 为 最 
佳 咒 探 嚣 ， 从 事 网 络 工 作 的 工程 师 都 知道 它 。 即 便 我 如 实地 列举 它 的 种 
种 好 处 ， 痢 涉嫌 违反 广告 法 。 这 也 许 就 是 我 的 上 一 本 书 《Wireshark 网 络 
分 析 就 这 么 人 简单》 得 以 多 次 重印 的 原因 ， 是 神器 总 会 流行 的 。 读 者 的 评 
价 也 超 乎 我 的 想象 ， 随 手 复制 两 条 书评 过 来 满足 一 下 我 的 虚 且 心 : 

“这 本 书 陪 了 我 几 个 深夜 。 没 有 大 部 头 的 催眠 和 艰 涩 ， 每 一 节 都 精炼 易 读 ， 和 咖啡 一 样 令 人 
上 瘤 。 我 是 网 络 小 新 人 ， 但 是 不 觉得 特别 难 ， 很 容易 顺 下 来 。 里 面 很 多 干货 ， 厚 积 薄 发 ， 都 是 
实际 环境 中 的 情况 。 畅 快 淋漓 读 完 大 呼 不 过 疗 ， 搜 了 一 下 作者 就 这 一 本 书 。 遗 憾 ! * 



































亚马逊 读者 

“这 本 书 是 我 2014 年 读 过 的 10 本 好 书 之 一 ， 如 果 说 我 对 这 本 书 有 什么 不 满 的 话 ， 就 只 有 一 
个 : 书写 薄 了 ， 意 犹 未 尽 ， 读 着 完全 不 过 闻 呀 呀 呀 。 或 许 这 本 书 浅 显 易 懂 、 幽 默 风趣 的 语言 风 
格 让 你 在 无 障碍 阅读 的 同时 ， 会 让 你 有 一 种 这 书 太 浅 、 适 合 初 学 者 的 感觉 ， 但 是 这 本 书 实际 上 
是 越 读 越 有 味道 ， 我 就 读 了 好 几 次 。” 



































一 豆瓣 读者 

既然 有 这 么 多 人 豆 欢 ， 我 有 什么 理由 不 再 写 一 本 呢 ? 于 是 就 有 了 这 

本 新 书 。 虽 然 我 在 写 稿 这 件 事情 上 的 拖延 症 不 亚 于 洗 碗 ， 不 过 读者 们 的 

或 励 显 然 起 了 作用 ， 最 后 收 笔 时 间 只 比 原 计划 晚 了 6 个 月 。 和 老 读 者 们 

期 望 的 一 样 ， 它 是 上 一 本 书 的 延续 ， 尤 其 是 在 写作 风格 上 。 不 同 之 处 在 

于 这 一 本 不 再 着 重 分 析 基 础 协议 ， 而 更 专注 于 解决 现实 问题 。 为 外 ， 考 

虑 到 现在 手机 上 网 日 趋 流行 ， 本 书 也 增加 了 一 些 手 机 App 的 内 容 ， 相 信 
读者 会 喜欢 。 





就 如 我 党 在 培训 课 上 所 讲 的 ， 学 会 Wireshark 这 个 软件 只 需要 几 个 小 
时 ， 和 擎 握 一 个 网 络 协议 也 用 不 了 几 天 ， 而 养 成 解决 问题 的 思路 却 需要 经 
年 囚 月 的 练习 和 思考 。 本 书 正 提供 了 很 多 练习 和 思考 的 机 会 ， 本 书 30 多 
篇 文章 ， 几 乎 都 用 了 Wireshark 来 分 析 网 络 包 。 我 希望 每 一 篇 都 能 让 读者 
产生 这 样 的 感触 :“ 啊 ， 原 来 Wireshark 还 可 以 这 样 用 ! *“ 读 完整 本 书 ， 
自然 而 然 会 形成 看 包 的 习惯 和 思维 方式 。 

本 书 组 织 结构 

就 像 时 尚 女 即 每 天 都 在 看 包 包 一 样 ， 我 也 每 天 都 在 看 包 。 看 到 有 趣 
又 有 价值 的 ， 就 会 记录 下 来 ， 久 而 久之 就 形成 了 这 本 书 。 因 此 它 有 别 于 
包罗 万 象 的 网 络 教材 ， 而 更 像 一 个 技术 博客 的 合集 。 

全 书 根据 素材 来 源 可 分 为 四 个 部 分 。 

第 一 部 分 的 选材 来 自 老 读者 的 咨询 ， 相 信 很 有 代表 性 ， 说 不 定 其 他 
读者 也 会 遇 到 。 

《Linux 为 什么 卡 住 了 》 分 析 了 登录 Linux 时 卡 顿 10 秒 钟 的 现象 。 虽 
然 我 是 Linux 领 域 的 羔 鸟 ， 但 是 仍然 可 以 用 Wireshark 发 现 原因 并 解决 


je 


尼 。 











`.《 像 福尔摩斯 一 样 思 考 》 讲 述 的 是 如 何 根据 网 络 包 中 的 蛛 丝 马 
迹 ， 找 到 被 人 为 掩 新 的 线索 。 上 自己 从 网 络 包 推 理 出 来 的 东西 ， 往 往 比 对 
方 提供 的 文档 更 可 靠 。 

.《 一 篇 关于 VMware 的 文章 》 介 绍 了 一 位 读者 在 VMware 知识 库 发 
现 的 文章 。 我 们 纯粹 依靠 协议 分 析 ， 找 到 了 这 篇 文章 的 真正 内 涵 ， 最 后 
再 用 Wireshark 看 包 加 以 确认 。 

《来 点 有 深度 的 》 是 在 上 一 篇 的 基础 上 ， 通 过 发 散 思 维 ， 回 读 
者 “灌输 ”了 一 些 相 关 的 TCP 知 识 。 个 人 和 觉得 TCP 协 议 理解 到 这 个 深度 就 
足够 应 付 大 多 数 性 能 问题 了 。 

`.《 三 次 握手 的 小 知识 》 是 应 某 论坛 网 友 的 要 求 而 写 的 TCP 握 手 科 
普 ， 分 享 了 一 些 用 Wireshatk 来 处 理 握 手 问 题 的 小 经 验 ， 顺 便 演 示 








了 “SYN flood” 攻 击 的 网 络 包 。 

《被 误解 的 TCP》 澄 清 了 被 读者 广泛 误解 的 两 个 TCP 概 念 ， 比 较 了 
Linux、Windows 和 安 卓 手机 的 不 同 Ack 频 率 。 

《最 经 典 的 网 络 问题 》 是 我 近年 遇 到 过 的 最 经 典 的 案例 了 。 虽 然 
很 多 年 前 就 听 说 过 Nagle 算 法 过 到 延迟 确认 会 出 问题 ,但 是 在 现实 中 还 
是 第 一 次 迪 到 ， 赶 紧 记 录 下 来 。 

《为 什么 于 了 单子 ? 》 讲 述 了 一 位 销售 朋友 的 遭遇 ， 说 明 用 
Wireshark 有 助 于 发 现 产 品 的 不 足 ， 并 且 找 到 改进 之 处 。 如 果 能 
Wireshark 分 析 自 家 产品 与 竞争 对 手 产 品 的 网 络 包 ， 一 定 能 找到 不 少 差 
别 ， 从 而 改进 销售 集 略 。 

`.《 受 损 的 帧 》 分 析 了 因为 硬件 等 原因 导致 帧 损坏 ， 从 而 在 
Wireshark 上 体现 出 的 奇怪 症状 。 事 情 往往 没有 表面 上 看 到 的 那么 简单 。 

《虚惊 一 场 》 是 因为 一 位 眼 尖 的 读者 发 现 了 我 书 中 的 一 处 * 错 
误 ”( 或 者 可 以 说 是 TCP 的 一 个 bug) ， 后 来 研究 了 很 久 才 发 现 是 虚惊 一 
场 ， 不 过 排查 过 程 还 是 很 值得 分 享 的 。 这 位 读者 还 从 “作者 简介 ”的 照 厂 
中 ， 看 到 我 手 上 的 《TCP/IP 详 解 卷 1: 协议 》 是 影印 版 ， 然 后 特意 从 美 
国 帮 我 寄 来 了 一 本 原版 书 。 再 次 表示 感谢 ! 

《NTLM 协 议 分 析 》 是 这 部 分 唯一 的 基础 协议 介绍 ， 据 说 NTLM 在 
中 国 用 得 还 很 多 ， 所 以 才 特意 写 了 一 篇 。 

《Wireshark 的 提示 》 收 集 了 读者 感 兴趣 的 很 多 Wireshark 提 示 信 
上 县。 文中 不 但 介绍 了 每 一 个 提示 信息 的 意义 ， 还 分 析 了 其 产生 的 原因 ， 
希望 让 读者 能 够 知 其 所 以 然 。 

第 二 部 分 是 我 自己 在 工作 中 过 到 的 网 络 问题 。 这 部 分 讲 得 最 细 、 最 
深 ， 问 题 本 身 也 最 复杂 。 在 阅读 这 一 部 分 时 ， 可 能 要 多 人 花 点 时 间 。 

“:《 书 上 错 了 吗 ?》 人 解释 了 为 什么 对 于 同一 个 TCP 连 接 ， 在 两 端 抓 到 
的 网 络 包 顺序 是 不 同 的 。 明 白 了 这 一 点 才能 理解 后 面 两 篇 的 内 容 。 

《计算 “在 途 字 节 数 ”》 介 绍 了 如 何 从 网 络 包 中 计算 “已经 发 送 但 未 












































被 确认 ”的 数据 量 。 不 用 害 人 数学， 简单 的 加 减法 就 够 用 了 。 

《估算 网 络 拥塞 点 》 在 前 两 篇 的 基础 上 ， 提 供 了 一 个 估算 网 络 拥 
塞 点 的 方法 。 掌 握 了 这 个 技能 ， 此 后 再 优化 TCP 性 能 时 束 脑 有 成 体 了 。 

《顺便 说 说 LSO》 讲 的 是 现在 越 来 越 普 裔 的 Large Segment 
Offload。 在 估算 拥塞 点 的 时 候 很 可 能 会 被 LSO 所 干扰 ， 因 此 我 特意 为 它 
写 了 一 篇 。 

-《 见 谈 RFC》 分 析 了 一 个 上 为 棘手 的 性 能 问题 ， 即 使 擅长 
Wireshark 也 很 难 解决 ， 同 大 家 展示 了 熟悉 RFC 的 重要 性 。 

.人 《一 个 你 本 该 能 解决 的 问题 》 用 Wireshark 分 析 了 一 个 UDP 导致 的 
性 能 问题 ， 从 本 质 上 分 析 UDP 和 TCP 的 差别 。 这 一 篇 我 在 微 博 上 发 过 ， 
还 引发 了 一 场 不 小 的 讨论 。 

`“《 几 个 关于 分 睛 的 问题 》 其 实 是 上 一 篇 的 后 续 。 很 多 读者 看 到 
UDP 包 被 分 片 之 后 出 现 了 性 能 问题 ， 所 以 对 分 片 很 感 兴趣 ， 问 了 不 少 问 


匮 。 








《MTU 导 致 的 恶 剧 》 分 享 了 几 个 MTU 配 置 出 问题 而 导致 的 事故 。 
这 类 问题 其 实 很 多 见 的， 尤其 是 对 于 实施 和 运 维 人 员 来 说 。 

《迎刃而解 》 是 来 自 一 个 运 维 部 门 的 技术 问题 ， 相 当 隐 蔽 而 且 将 
异 ， 最 终 在 Wireshark 的 辅助 下 迎刃而解 。 

《县 花 一 现 的 协议 》 回 忆 了 一 个 我 曾经 文 持 过 的 协议 。 今 天 才学 
习 它 可 能 没有 实际 意义 ， 但 是 其 理念 和 创意 还 是 值得 借鉴 的 。 当 你 对 一 
个 协议 了 解 到 一 定 程度 时 ， 表 定 也 会 有 改造 它 的 想法 。 

:《 男 一 种 流 控 》 介 绍 的 是 Pause ”Frame (暂停 帧 ) 流 控 。 有 别 于 
TCP 的 “并 到 端 ” 流 控 ， 它 是 “点 到 点 ”的 ， 在 有 些 场 合 很 好 用 。 

《过 犹 不 及 》 分 享 了 一 个 多 线程 传输 的 案例 ， 说 明 不 是 增加 连接 
数 束 一 定 能 提高 性 能 ， 有 时 候 甚 至 有 人 负面 效果 。 

.《 治 疗 强迫 症 》 演 示 了 如 何 用 Wireshark 研 究 文本 编辑 软件 的 工作 
方式 。 也 许 这 类 软件 不 是 你 的 兴趣 所 在 ， 但 是 可 以 举一反三 ， 用 相同 的 








方式 研究 其 他 软件 。 

《技术 与 工龄 》 算 是 半 篇 技术 文章 。 除 了 介绍 Window Scale 这 个 技 
术 点 ， 还 希望 每 个 人 都 能 正视 工龄 ， 善 竺 新 人 。 

《一 个 面试 建议 》 只 是 分 享 面试 经 验 ， 完 全 无 关 技 术 。 文 章 写 得 
很 不 严肃 ， 目 的 是 让 读者 休息 一 下 ， 乐 一 乐 。 

《如 何 科学 地 推 抒 责任 》 不 是 想 把 你 “ 教 二 ”"， 而 是 分 享 了 如 何在 
技术 上 划分 贡 任 。 如 果 你 是 乙方 工程 师 ， 肯 定 会 需要 的 。 

第 三 部 分 的 选材 是 日 常生 活 中 的 抓 包 ， 包 括 手机 App。 在 未 来 一 两 
年 ， 可 能 会 有 越 来 越 多 的 人 去 抓 手 机 上 的 包 ， 因 为 用 得 多 了 ， 问 题 也 会 
跟着 增加 。 

-《 假 宽带 真相 》 本 是 央视 某 一 期 节目 的 名 字 ， 说 测速 软件 “有 明显 
的 设计 缺陷 *。 我 用 Wireshark 进 行 了 验证 ， 结 末 如 何 呢 ? 读 了 全 文 就 知 
道 了 。 

《手机 抓 包 》 讲 解 的 是 如 何在 家 里 搭建 适合 抓 手 机 包 的 WiFi 环 
境 。 如 果 你 经 常 需要 抓 手机 上 的 包 来 研究 ， 相 信 我 ， 是 该 改造 一 下 家 里 
的 网 络 了 。 

-《 微 博 为 什么 会 卡 》 分 析 了 微 博 在 WiFi 环 境 下 经 常 卡 顿 的 问题 ， 
最 后 找 出 来 的 原因 竟然 是 DNS。 本 文 对 很 多 App 的 优化 有 借鉴 作用 。 

《寻找 HttpDNS》 讲 述 了 一 个 “失败 ”的 探索 过 程 ， 因 为 到 最 后 都 没 
有 找到 想 要 的 包 。 不 过 失败 本 号 也 有 价值 ， 因 为 我 们 知道 了 真相 不 过 如 
| 由 

`《 谁 动 了 我 的 网 络 》 详 细 地 讲解 了 被 劫持 的 网 络 包 有 什么 特征 ， 
以 及 如 何在 Wireshark 中 找到 它们 。 下 一 次 你 怀疑 自家 网 络 被 劫持 时 ， 驶 
可 以 抓 一 个 包 自 己 分 析 了 。 

《一 个 协议 的 进化 》 介 绍 的 是 当前 HTTP 1.1 在 性 能 上 的 落后 之 
处 ， 以 及 可 能 改进 的 空间 。 可 惜 现在 HITP 2 的 包 还 不 容易 抓 到 ， 人 否则 
我 们 还 可 以 增加 一 些 内 容 。 





:《 假 朔 产品 经 理 》 分 析 了 在 微 博 发 图 片 的 网 络 包 ， 我 们 可 以 从 中 
看 到 它 的 压缩 比例 、 上 传 行为 、CDN 服 务 商 等 。 不 用 派 卧 底 去 新 浪 ， 就 
可 以 侦察 到 不 少 “ 机 密 ?”。 

《和 目 学 的 穹 门 》 也 无 关 技 术 ， 只 是 分 享 了 本 人 的 学 习 经 验 ， 和 希望 





对 新 人 有 些 参考 价值 。 
第 四 部 分 的 内 容 很 少 ， 却 花费 了 我 不 少时 间 ， 因 为 写 的 是 两 个 项 
目 / 产 品 。 





《打造 自己 的 分 析 工 具 》 介 绍 了 我 自己 打造 的 一 个 性 能 分 析 网 
站 ， 让 大 家 体验 一 下 量 身 定制 的 工具 有 多 好 用 。 本 文 也 分 享 了 开发 过 程 
的 一 些 经 验 。 

《一 个 创业 点 子 》 讲 的 是 我 兽 经 想 做 的 一 个 网 络 加 速 器 。 里 面 知 
识 点 还 是 挺 多 的 ， 也 适合 用 Wireshark 来 研究 。 

你 可 能 会 问 的 一 些 问题 

1. 阅读 此 书 需要 什么 基础 ? 

只 需要 具备 网 络 常 识 ， 比 如 在 学 校 里 上 过 网 络 课 或 者 考 过 CCNA 就 
够 了 了。 如 采 读 过 《Wireshark 网 络 分 析 就 这 么 简单 》 是 最 好 的 ， 会 觉得 衔 
接 顺 畅 。 对 于 缺乏 网 络 基 础 的 Wireshark 用 户 ， 建 议 先 阅读 Richard 
Stevens 的 《TCP/P 详 解 卷 1:， 协议 》。 英 文 好 的 读者 可 以 通过 
http://www.tcpipguide.com/free/index.htm 页 面 免费 阅读 《The TCP/IP 
Guide》 一 书 ， 里 面 的 插图 男 得 尤其 好 。 由 于 读 免 费 书籍 很 难 坚 持 下 
去 ， 你 可 以 点 击 页 面 下 方 的 Donate 按 钮 给 作者 捐款 ， 由 此 增加 进一步 学 
司 购 码 方 : 

2. 本 书 的 选材 为 何如 此 广泛 ? 

我 写 这 本 书 是 为 了 让 读者 学 有 所 获 ， 因 此 选材 也 从 读者 的 兴趣 点 出 
发 。 比 如 现在 流行 手机 上 网 ， 因 此 我 增加 了 这 部 分 的 内 容 ; 又 比如 技术 
立正 在 热 议 HttpDNS， 所 以 我 束 去 做 了 一 系列 实验 ...... 不 同 读者 的 关注 
点 肯定 会 有 所 不 同 ， 如 果 某 一 篇 的 话题 不 是 你 感 兴趣 的 ， 直 接 跳 过 也 不 











影响 后 面 的 阅读 。 

3. 为 什么 我 觉得 有 些 内 容 太 简单 了 ? 

人 们 读书 时 都 会 有 这 样 的 反应 一 一 读 到 自己 不 慌 的 内 容 时 ， 束 会 觉 
得 高 大 上 ; 读 到 自己 擅长 的 领域 时 ， 又 会 觉得 太 简 单 。 这 就 是 为 什么 有 
些 作 者 喜欢 把 书写 得 很 玄 平 ， 然 而 我 的 风格 恰恰 相反 ， 会 尽 可 能 地 把 复 
杂 的 问题 简单 化 。 我 的 技术 培训 也 是 坚持 这 样 的 风格 ,会 假设 所 有 听众 
都 是 刚 毕 业 的 文科 妹子 〈 嗯 ， 这 样 也 会 使 我 的 心情 好 一 些 ) 。 

4. 为 什么 没有 随 书 光 盘 ? 

我 也 希望 能 把 这 本 书 里 的 网 络 包 都 共享 出 来 ， 但 由 于 大 多 是 在 客户 
的 生产 环境 中 抓 到 的 ， 所 以 不 适合 公开 。 上 毕竟 从 包 里 能 暴露 出 来 的 安全 
隐患 太 多 了 ， 项 望 读者 能 理解 这 个 否 囊 。 为 了 方便 阅读 ， 我 已 经 尽量 把 
Wireshark 截 图 做 清晰 。 建 议 大 家 在 自己 的 环境 中 抓 包 分 析 ， 这 会 比 看 示 
例 包 更 有 价值 。 

5. 怎样 联系 作者 ? 

如 果 对 书 中 的 内 容 有 疑问 ， 或 者 自己 抓 了 包 却 不 知道 怎么 分 析 ， 都 
可 以 联系 作者 ， 邮 箱 地 址 为 linpeiman@hotmail.com。 你 也 可 以 在 微 博 上 
@ 林 沛 满 ， 但 不 建议 关注 ， 因 为 他 是 个 整 天 晒 园 亏 图 片 的 话 疾 。 














、 My 
从; 击 老 向 


在 过 去 几 年 中 ， 有 不 少 读者 、 同 事 和 网 友 辐 我 咨询 过 网 络 问题 ， 其 
中 大 部 分 都 记录 在 案 。 我 一 直 把 这 些 案 例 视 为 珍 贯 的 财富 ， 因 为 既 真 实 
又 有 广泛 的 代表 性 ， 比 我 自己 在 实验 室 中 “制造 出 来 的 好 多 了 。 本 书 从 
中 选择 了 最 经 典 的 部 分 ， 和 希望 读者 会 感 兴趣 。 如 果 你 在 工作 或 生活 中 巡 
到 网 络 问题 ， 也 欢迎 抓 个 包 来 找 我 分 析 。 








Linux， A i 





到 今天 为 止 ， 已 经 有 5 位 读者 向 我 求助 过 这 个 问题 了 。 症 状 请 看 图 





1， 他 们 通过 SSH 登 录 Linux 服 务 器 时 ， 输 完 用 户 名 就 卡 住 了 ， 要 等 待 10 
秒 钟 才 提示 密码 输入 。 这 究竟 是 什么 原因 导致 的 呢 ? 其 实 我 也 是 Linux 
瑟 鸟 ， 虽 然 尝 试 过 搜索 “ssh hang” 等 关键 词 ， 但 是 没 找到 相关 信息 。 





图 1 

10 秒 钟 的 时 间 并 不 算 长 ， 吃 个 暮 片 喝 口 咖 啡 就 过 去 了 。 但 是 作为 强 
迫 症 患 者 ， 我 还 是 容 不 得 它 的 存在 ， 因 此 便 决 定 写 篇 文章 ， 同 大 家 演示 
一 下 怎样 用 Wireshark 一 步 步 解决 这 个 问题 。 

站 先是 抓 包 ， 步 又 如 下 。 

1. 在 Linux 服 务 器 上 启动 抓 包 。 

2. 从 笔记 本 SSH 到 Linux 服 务 器 ， 输 入 用 户 名 并 回 车 。 

3. 等 待 10 秒 左右 ， 直 到 登录 界面 提示 输入 密码 。 

4. 停止 抓 包 。 

这 样 束 可 以 得 到 一 个 涵盖 该 现象 的 网 络 包 了 。 一 般 在 实验 室 中 没有 











干扰 流量 ， 不 用 过 滤 也 可 以 分 析 ， 不 过 我 们 最 好 在 做 实验 时 就 养 成 过 滤 
的 习惯 ， 以 适应 生产 环境 中 抓 到 的 包 。 因 为 我 们 是 通过 SSH 协 议 登 录 
的 ， 所 以 可 以 直接 用 “ssh” 来 过 小， 如 图 2 所 示 。SSH 包 都 是 加 密 了 的 ， 


因此 我 们 看 不 出 每 个 包 代表 了 什么 意思 ， 不 过 这 并 不 





中 可 以 看 到 ，21 号 包 和 25 号 包 之 间 恰 好 就 相隔 10 秒 。 


|-] Expression.. Clear Apply Save 


Fiter | ssh 


No, Time 


10 0.019267 
11 0.023411 
12 0.128382 
14 0.180761 
15 0.344019 
17 0.344116 
19 0.344196 
21 1.661846 
25 11.664153 
26 11.664160 
28 11.667277 
30 11.668867 
34 13.548907 
35 13.550799 
30 E3534533 
37 13.553077 








Source 本 
Laptop 
Linux_server 
Laptop 
Linux_server 
Laptop 
Laptop 
Linux_server 
Laptop 
Linux_server 
Linux_server 
Laptop 
Linux_server 
Laptop 
Linux_server 
Laptop 
Linux_server 


Destination 
Linux_server 
Laptop 
Linux_server 
Laptop 
Linux_server 
Linux_server 
Laptop 
Linux_Sserver 
Laptop 
Laptop 
Linux_server 
Laptop 
Linux_server 
Laptop 
Linux_server 
Laptop 


Protocol 


SSHV2 
SSHV2 
SSHVv2 
SSHV2 
SSHV2 
SSHV2 
SSHV2 
SSHVv2 
ssSHv2 
SSHV2 
SSHVv2 
SSHVz 
SSHV2 
SSHVz 
SSHV2 
SSHV2 


Info 


Client: 
Server: 
Client: 
Server: 
Client: 
Client: 
Server: 
Client: 
Server: 
Server: 
Client: 
Server: 
Client: 
Server: 
Client: 
Server : 


图 2 
这 两 个 包 之 间 所 发 生 的 事件 ， 可 能 就 是 导致 这 个 现象 的 原因 。 于 是 
我 再 用 “frame.number>21 & 上 frame.number<25” 过 滤 ， 结 果 如 图 3 所 示 。 


影响 分 析 。 从 图 2 


Diffie-Hellman Group Exchange Request (01d) 
Diffie-Hellman Group Exchange Group 
Diffie-Hellman Group Exchange Init 
Diffie-Hellman Group Exchange Reply, New Keys 


New Keys 

Encrypted packet 
Encrypted packet 
Encrypted packet 
Encrypted packet 
Encrypted packet 
Encrypted packet 
Encrypted packet 
Encrypted packet 
Encrypted packet 
Encrypted packet 
Encrypted packet 


(len=52) 
(len=52) 
(len=68) 
(len=1460) 
(len=100) 
(len=100) 
(len=84) 
(len=296) 
(len=36) 
(len=68) 
(len=52) 





Filter: | frame.number > 21 && frame.number < 25 


No. Time 
22 1.662507 
23 1.701128 
24 6.661771 


Source 


Linux_server 
Linux_server 
Linux_server 


Destination 
DNS_Server 
Laptop 
DNS_Server 


[>| Expression.. Clear Apply Save 


Protocol Info 
standard query Oxcbfe PTR 23.200.32.10.in-addr.arpa 
22-57579 [ACK] Seq=2498 Ack=1381 Win=8544 Len=0 

standard query Oxcbfe PTR 23.200.32.10.in-addr.arpa 


DNS 
TCP 
DNS 


图 3 
从 图 3 中 可 以 看 到 ，Linux 服 务 器 当时 正 忙 着 向 DNS 服务 器 查询 
10.32.200.23 的 PTR 记 录 《 即 反 回 解析 ) ， 试 图 获得 这 个 下 地 址 所 对 应 的 
域名 。 该 下属 于 我 们 测试 所 用 的 笔记 本 ， 但 由 于 DNS 服务 器 上 没有 它 的 
PTR 记 录 ， 所 以 两 次 查询 都 等 了 5 秒 钟 还 没 结果 ， 总 共 浪 费 了 10 秒 钟 。 

我 们 由 此 可 以 推出 ， 这 台 Linux 服 务 器 在 收 到 SSH 访 问 请 求 时 ， 会 
先 查 询 该 客户 端 IP 所 对 应 的 PTR 记 录 。 假 如 经 过 5 秒 钟 还 没有 收 到 回 











复 ， 就 再 发 一 次 查询 。 如 果 第 二 次 查询 还 是 等 了 5 秒 还 没 回 复 ， 就 彻底 
放弃 查询 。 我 们 甚至 可 以 进一步 猜测 ， 如 果 DNS 查 询 能 成 功 ， 就 不 用 白 
等 那 10 秒 钟 了 。 


为 了 验证 这 个 猜测 ， 


录 ， 如 图 4 所 示 ， 然 后 再 次 登录 。 


品 ， dnsmgmt - [DNSs\DC1\Reverse Lookup Zones‘10.32.200.x Subnet] 


我 在 DNS 服 务 器 中 添加 了 10.32.200.23 的 PTR 记 





访 File 


Action Yew ‘Window Help 





和 小 | 向 | 加 | 办 加 区 | 岛国 | 目 自 生 






























































-la nas.com 

| Reverse Lookup Zones 

时 10.32.106.x Subnet 

{Ej 10.32.16.x Subnet 

Ed 10,32,190,x Subnet 
10,32,23,x Subnet 

{Ej 10.71.34.x Subnet 





“8 10,32,200,x Subnet 
基 Event Yiewer 


(same as parent Folder) l 


目 (same as parent folder) 
和 目 (same as parent folder) 





图 4 


Name Server (NS) 
Name Server (NS) 
Start of Authority (SOA) 


dcl,nas,com， 
dc2,nas,com， 
[2], dcl,nas,com,, hostmas,,， 


Ms 


这 一 次 果然 立即 登录 进去 了 。 从 图 5 的 Wireshark 稚 屏 可 见 ，DNS 奋 
询 是 成 功 的 ， 所 以 21 号 包 和 26 号 包 之 间 几 乎 是 没有 时 间 停 顿 的 。 














No. Time Source Destination Protocol Info 
137 0.354656 laptop.nas.com Linux_server SSHv2 Client: Encrypted packet (len=52) 
18 0.354689 Linux_server laptop. nas. com TCP 22-~58426 [ACK] Seq=2446 Ack=1313 Win=8544 Len=0 
19 0.354756 Linux_server laptop. nas. com SSHV2 Server: Encrypted packet (len=52) 
20 0.562055 laptop.nas.com Linux_server TCP 58426-22 [ACK] Seq=1313 Ack=2498 Win=65536 Len=0 
2 1.444473 laptop.nas.com Linux_server SSHv2 Client: Encrypted packet (len=68) 
22 1.445674 Linux_server DNS_Server DNS standard query Oxda56 PTR 23.200.32.10.in-addr.arpa 
23 1.445870 DNS_Server Linux_server DNS standard query response Oxda56 PTR laptop.nas.com 
24 1.446147 Linux_serVver DNS_Server DNS standard query 0xla68 A laptop.nas.com 
25 1.446319 DNS_SerVver Linux_server DNS standard query response 0xla68 A 10.32.200.23 
26 1.455106 Linux_server laptop. nas. com SSHV2 Server: Encrypted packet (len=1460) 
27 1.455116 Linux_server laptop. nas. com SSHv2 Server: Encrypted packet (len=100) 
28 1.455806 laptop.nas.com Linux_server TCP 58426-22 [ACK] seq=1381 Ack=4058 Win=65536 Len=0 
29 1.458199 laptop.nas.com Linux_server ssHv2 Client: Encrypted packet (len=100) 
30 1.459701 Linux_server laptop. nas. com SSHV2 Server: Encrypted packet (len=84) 
图 5 
» 2 My | >» Y 2. AP 
明白 了 DNS 查 询 就 是 问题 的 起 因 ， 接 下 来 就 知道 怎么 进一步 研究 
第 ， 
了 。 只 要 在 Google 搜 索 “ssh dns”， 第 一 页 出 来 的 链接 都 是 关于 这 个 问题 
有 | “二 让 连 . » 六 请 人 已 BE 下 日 
的 。 随 便 挑 几 篇 阅读 一 下 ， 就 连 我 这 样 的 Linux 初 学 者 都 能 把 这 个 问题 


研究 透 了 。 原 来 这 个 行为 是 定义 在 %etc/ssh/sshd_config” 文 件 中 的 ， 默 认 
配置 是 这 样 的 : 
[root@Linux_Server~ |]#cat/etc/ssh/sshd_config|grep-i usedns 
#UseDNS yes 
改 成 下 面 这 样 就 可 以 解决 了 ， 不 用 去 动 DNS 服务 右上 的 配置 : 


[root@Linux_Server~ |]#cat/etc/ssh/sshd_config|grep-i usedns 


UseDNS no 
我 经 和 常 说 技能 比 知 识 更 重要 ， 这 就 是 例子 之 一 。 学 会 了 使 用 
Wireshark， 其 他 知识 也 会 跟着 来 的 。 





有 位 读者 在 豆 因 上 评论 我 的 上 一 本 书 ， 说 有 阅读 侦探 小 说 的 感觉 。 
我 对 此 并 不 觉得 惊讶 ， 因 为 用 Wireshark 排 查 问题 ， 和 侦探 破案 的 思路 是 
一 致 的 。 神 探 福尔摩斯 的 破案 秘诀 是 “ 调 因 推理 ”一 一 先 观 峙 所 有 细节 ， 
比如 鞋 根 上 的 泥 疙 将 其 至 烟灰 ， 然 后 作出 多 种 推理 和 假设 ， 接 痢 刨 去 各 
种 不 可 能 ， 最 后 剩 下 的 “无 论 多 么 难以 置信 ， 肯 定 没 错 。” 用 Wireshark 分 
析 网 络 包 时 也 类 似 ， 我 们 先 要 在 网 络 包 中 寻找 各 种 线索 ， 然 后 根据 网 络 
协议 作出 推理 ， 接 着 刨 去 人 为 《有 间或 无 意 ) 掩盖 的 证 据 ， 才 能 得 到 最 
后 的 真相 。 尤 其 是 和 保密 机 构 打 交道 的 时 候 ， 工 程 师 进 不 了 机 房 ， 文 档 
也 不 能 公开 ， 所 以 一 切线 索 只 能 目 己 在 包 里 找 ， 感 党 就 更 像 破案 了 。 

我 最 近 帮 一 位 读者 解决 的 问题 就 非常 典型 。 他 供职 的 机 构 内 部 网 站 
有 时候 会 发 生 诡 异 的 现象 ， 比 如 Web 服 务 器 的 端口 号 会 随机 发 生变 化 
(具体 症状 就 不 多 讲 了， 和 本 文 关系 不 大 ) 。 后 来 做 了 排查 ， 把 客户 端 
和 Web 服 务 占 直 连 ， 问 题 就 消失 了 ， 确 认 了 了 Web 服务器 和 客户 闻 痢 没有 
问题 。 难 道 根 本 原因 惑 出 在 网 络 路 径 上 了 ? 可 是 管理 员 叉 声称 网 络 拓 扑 
非常 简单 ， 不 会 出 问题 的 。 见 图 1， 客 户 问 和 Web 服 务 需 在 不 同 的 子 网 
里 ， 中 间 由 一 个 路 由 器 转发 。 





























Web 服 务 器 





攒 我 的 经 验 ， 这 个 网 络 拓扑 的 确 简单 到 没有 出 问题 的 可 能 。 可 是 已 
经 到 了 山 穷 水 尽 的 地 步 了 ， 只 好 抓 包 试 试 。Web 服 务 器 不 允许 我 们 登 
录 ， 所 以 只 能 在 客户 端 抓 ， 更 粳 糕 的 是 抓 包 时 那个 说 异 的 现象 并 没有 发 
生 。 你 一 定 会 纳 问 ， es 看 头 啊 ? 人 在 走投无路 的 时 
候 ， 要 求 都 是 很 低 的 ， 能 抓 到 一 点 算 一 点 。 图 2 就 是 抓 到 的 包 ， 看 起 来 
一 切 都 很 正常 : 前 3 个 包 是 三 次 握手 ， 楼 着 窑 户 山 发 了 个 HTTP ”GET 请 
求 ， 服 务 器 也 确认 收 到 了 。 











No. Time Source Destination Protocol Info 
1 0.000000000 Client Web_server TCP 3106-80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 SACK_I 
2 0.004205000 Web_server Client TCP 80-~3106 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1460 
3 0.004212000 Client Web_server TCP 3106-~80 [ACK] Seq=1 Ack=l Win=65536 Len=0 
4 0.162915000 Client Web_server HTTP GET / HTTP/1.1 
5 0.163066000 Web_server Client TCP 80~3106 [ACK] Seq=1 Ack=385 Win=30336 Len=0 
图 2 


既然 表面 上 都 是 好 的 ， 我 们 再 看 看 每 个 包 的 详细 信息 。1 号 包 的 详 
情 见 图 3， 客 户 端 把 包 交 给 了 一 个 叫 c0:62:6b:e2:bd:88 的 MAC 地 址 ， 该 地 
址 属于 默认 网 关 。 将 包 交 给 默认 网 关 是 合理 的 ， 因 为 Web 服 务 器 在 另 一 
个 子 网 中 ， 需 要 路 由 转发 。 也 就 是 说 ， 从 1 号 包 中 没有 发 现任 何 异常 。 


No. Time Source Destination Protocol Info 
1 0.000000000 Cclient Web_server TCP 3106-~80 [SYN] Seq=0 Win=65535 Len=0 MSS=14 
2 0.004205000 Web_server Client TCP 80-~3106 [SYN, ACK] Seq=0 Ack=1 Win=29200 L 
3 0.004212000 Client Web_server TCP 3106~80 [ACK] Seq=1 Ack=1 Win=65536 Len=0 
4 0.162915000 Client Web_server HTTP GET / HTTP/1.1 
5 0.163066000 Web_server Client TCP 80-3106 [ACK] Seq=1 Ack=385 Win=30336 Len= 


U4 


[Erame i: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0 
由 Ethernet II, Src: |00:50:56:8a:25:52 (00:50:56:8a:25: 52), Dst: :@2:bd: 


日 Internet Protocol Version 4, Src: Client ( 192.168.111.111 ) Dst: Web_server 92. 168.222.222) 


图 3 
再 看 看 图 4 的 2 号 包 详 情 。 这 个 包 让 人 眼前 一 亮 ， 信息 量 实在 太 大 
了 。 在 阅读 下 面 的 文字 之 前 ， 建 议 你 自己 先 在 图 中 找 找 亮 点 。 












No Time Source Destination protocol Info 


1 0.000000000 Client Web_server TCP 3106-~80 [SYN] Seq=0 Win=65535 Len=0 MSS= 
2 0.004205000 Web_server Client TCP 80-3106 [SYN, ACK] Seq=0 Ack=1 Win=29200 
3 0.004212000 Client Web_server TCP 3106-~80 [ACK] Seq=1 Ack=1 Win=65536 Len= 
4 0.162915000 Client Web_server HTTP GET / HTTP/1.1 

5 0.163066000 Web_server Client TCP 80-3106 [ACK] Seq=1 Ack=385 Win=30336 Le 
| 








[Erame 下 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0 

四 Ethernet II, Src: |00:10:f3:27:61:86| (00:10:f3:27:61:86), Dst: [|00:50:56:8a:25:52| (00:50::! 

日 INternet Protocol Version 4, Src: Web_server (192.168.222.222), Dst: Client ( 192.168.111.111 
Version: 4 


Header Length: 20 bytes 
四 Differentiated services Field: Ox00 (DsCP Ox00: Default; ECN: Ox00: Not-ECT (Not ECN-C 


Total Length: 52 
Identification: Ox0000 (0) 
田 Flags: Ox02 (Don t Fragment) 


Fragment offset: 0 
图 4 


首先 这 个 包 竟 然 是 从 MAC 地 址 00:10:f3:27:61:86 发 过 来 的 ， 而 不 是 
之 前 提 到 的 默认 网 关 c0:62:6b:e2:bd:88。 我 不 知道 这 个 MAC 地 址 属于 什 
么 设备 ， 但 这 至 少 说 明 2 号 包 和 1 号 包 走 了 条 不 一 样 的 路 径 。 再 看 其 Time 
to live TTL) 居然 是 64， 理 论 上 经 过 一 次 路 由 的 包 ，TTL 应 该 减 去 1， 
变 成 63 才 对 。 根 据 这 两 条 信息 ， 可 以 推测 管理 员 提 供 的 拓扑 图 有 误 。 真 
正 的 网 络 包 流 同 应 该 接近 图 5， 即 客户 端 发 出 去 的 包 是 经 过 路 由 的 ， 而 
Web 服 务 器 发 过 来 的 包 没 经 过 路 由 。 























客户 端 Web 服 务 器 
图 5 

其 实 到 这 里 就 可 以 去 找 管理 员 说 理 了 ， 不 过 别 急 ， 继 续 往 下 看 。 到 
了 图 6 的 第 5 号 包 ， 发 现 Identification 竟 然 是 49031， 而 同样 是 来 自 Web 服 
务 器 的 2 号 包 ( 见 图 4) 中 ，Identification 却 是 0。 一 般 发 出 Identification 
为 0 的 机 器 永远 都 发 909， 不 会 一 下 子 跳 到 49031。 也 束 是 说 ， 其 实 2 写 包 和 
5 号 包 是 两 台 不 同 的 设备 发 出 来 的 ， 这 意味 着 在 Web 服 务 器 和 客户 端 之 
间 ， 可 能 存在 一 台 设 备 在 代理 三 次 握手 ， 而 能 够 代理 握手 的 设备 很 可 能 
是 应 对 Syn flood 攻 击 的 防火 墙 。 














No， Time 

0. 000000000 
0.004205000 
0.004212000 
0.162915000 
0.163066000 


wm 人 mwN 情 


Source Destination 
Client Web_server 
Web_server Client 
Client Web_server 
Client Web_server 


Web_server Client 


Protocol Info 
TCP 


TCP 
TCP 
HTTP 
ER 


3106-80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 W 
80-~3106 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 
3106-80 [ACK] Seq=1 Ack=1 Win=65536 Len=0 

GET / HTTP/1.1 

80-3106 [ACK] Seq=1 Ack=385 Win=30336 Len=0 





Ul 





Version: 4 





Header Length: 20 bytes 
由 Differentiated Services Field: Ox00 (DsCP Ox00: Default; ECN: Ox00: Not-ECT (Not ECN-Capable 
Total Length: 40 
田 Flags: Ox02 (Don't Fragment) 


Fragment offset: 0 
Time to live: 64 


图 6 


四 [Erame 引 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 
四 Ethernet II, Src: 00:10:f3:27:61:86 (00:10:f3:27:61:86), Dst: 00:50:56:8a:25:52 (00:50:56:8a:2 
日 Internet Protocol Version 4, src: Web_server (192.168.222.222), Dst: Client ( 192.168.111.111 ) 


因此 图 5 的 拓扑 图 还 不 够 准确 ， 应 该 更 正成 图 7 的 样子 。 管 理 员 忽视 


了 这 台 防 火 墙 ， 








客户 端 


~/ 





可 能 就 错过 了 及 现 问题 根源 的 机 会 。 





防火 墙 Web 服务 器 


把 以 上 分 析 反 馈 给 管理 员 之 后 ， 他 果然 通过 MAC 地 址 
00:10:f3:27:61:86 找 到 了 一 台 防 火 墙 。 也 正 是 防火 墙 上 的 一 些 错误 配 
置 ， 导 致 他 们 遇 到 了 那些 诡异 症状 ， 改 正之 后 症状 就 消失 了 。 本 文 的 目 








的 是 演示 如 何在 网 络 包 中 寻找 被 掩盖 的 线索 ， 而 不 是 防火 墙 知 识 ， 所 以 


就 不 展开 了 。 





从 头 到 尾 再 复习 一 下 整个 过 和 





口 





TT 


， 是 不 是 很 有 当 侦 探 的 感觉? 


注意 : 为 了 保护 客户 隐私 ， 本 文 截图 
截图 看 





上 去 不 太 上 自然。 























的 耳 地 址 和 MAC 地 址 都 被 PS 过 ， 这 束 是 为 什么 有 些 








一 篇 关于 VMware 具 文章 


有 位 读者 在 VMware 的 知识 库 里 找到 一 篇 文章 ， 觉 得 很 像 他 正在 遭 
遇 的 一 个 性 能 问题 ， 便 转发 给 我 确认 。 作 为 好 为 人 师 的 技术 员 ， 我 当然 
不 能 让 读者 失望 。 

这 篇 文章 大 概 讲 了 这 样 一 件 事 。 

问题 描述 

某 些 iSCSI 存储 阵列 在 出 现 网 络 拥塞 时 处 理 不 当 ， 会 严重 影响 
VMware 的 读 写 性 能 。 这 和 它们 的 TCP 实 现 方式 有 关 。 

解决 方式 

在 VMware 和 存储 阵列 上 关闭 延迟 确认 (Delayed ACK) 

VMware 和 iSCSI 存储 阵列 是 什么 ? 我 在 知识 库 里 找到 一 个 网 络 拓 
扑 ， 看 起 来 很 简单 ， 大 概 如 图 1 所 示 。 我 们 无 需 理 解 得 很 深 只 要 把 
iSCSI 存储 阵列 当 作 一 台 服 务 器 ， 再 把 VMware 当 作 其 客户 端 就 行 了 ， 两 
者 通过 以 太 网 传输 数据 。 











Ethernet 





iSCSI 存储 阵列 


图 1 

乍 一 看 ， 这 个 “问题 描述 ?与 “解决 方式 ”简直 风 马 牛 不 相 及 。 网 络 拥 
塞 怎么 能 靠 关 闭 延 迟 确认 来 解决 ? 不 过 出 于 对 VMware 的 一 贯 信任 ， 我 
决定 还 是 好 好 研究 一 下 。 

我 们 先 要 明白 什么 叫 延迟 确认 ， 它 可 以 用 一 个 简单 的 例子 来 说 明 : 
在 上 海 的 笔记 本 上 启动 Wireshark 抓 包 ， 然 后 用 Putty 远 程 登录 一 台 位 于 
悉尼 的 服务 器 。 由 图 2 可 见 ， 在 上 海 发 出 一 个 SSH 请 求 之 后 ， 经 过 149 尝 
秒 左 右 〈 即 1 号 包 和 2 号 包 之 则 的 时 间 差 ) 收 到 了 悉尼 的 回复 ， 这 是 正常 
的 往返 时 间 。 但 是 笔记 本 收 到 回复 之 后 ， 却 没有 立即 确认 ， 而 是 延迟 了 
200 毫 秒 以 上 《〈 即 2 号 包 和 3 号 包 之 间 的 时 间 差 ) 才 确 认 。 








No,， Time Source Destination Protocol Info 


1 0.000000 shanghai sydney SSH Client: Encrypted packet (len=52) 

2 0.148774 Sydney shanghai SSH server: Encrypted packet (len=52) 

3 0.363628 shanghai sydney TCP 64839-22 [ACK] Seq=53 Ack=53 Win=254 Len=0 
图 2 


这 个 现象 就 是 传说 中 的 延迟 确认 ， 我 在 上 一 本 书 中 也 介绍 过 。 为 了 
让 大 家 更 好 地 理解 它 ， 我 们 再 做 个 对 比 实验 : 我 在 笔记 本 上 关闭 了 延迟 
确认 ， 然 后 再 次 连接 悉尼 的 服务 器 。 从 图 3 可 见 2 号 包 和 3 号 包 之 间 几 乎 
没有 时 间 差 了 (只 有 0.000121 秒 ， 可 以 忽略 》。 





No, Time Source Destination Protocol Info 
1 0.000000 shanghai sydney SSH Client: Encrypted packet (len=52) 
2 0.148575 Sydney shanghai SSH server: Encrypted packet (len=52) 
3 0.148696 shanghai sydney TCP 1207~22 [ACK] Seq=53 Ack=53 Win=63928 Len=0 
图 3 


司 用 延迟 确认 是 有 好 处 的 ， 假 如 在 这 等 待 的 200 坚 秒 里 ， 上 海 的 笔 
记 本 恰好 有 数据 要 发 ， 就 可 以 在 发 数据 时 捐 带 确认 信息 ， 省 去 了 一 个 纯 
粹 的 确认 包 。 图 4 就 符合 这 种 情况 。 笔 记 本 收 到 11 号 包 之 后 ， 等 了 41 毫 
秒 左右 〈 即 11 号 包 和 12 号 包 之 间 的 时 间 差 ) 恰 好 又 有 一 个 SSH 请 求 要 
发 ， 就 顺便 把 确认 撒 带 过 去 了 ， 因 此 省 掉 了 一 个 纯粹 的 确认 包 。 之 所 以 











有 很 多 TCP 协 议 栈 默 认 局 用 延迟 确认 ， 正 是 基于 这 个 原因 一 一 少 一 些 确 
认 包 可 以 节省 带宽 嘛 。 
0， Time Source Destination Protocol Info 
10 1.498030 shanghai sydney SSsH Client: Encrypted packet (len=52) 
11 1.646575 ”Sydney shanghai ssH server: Encrypted packet (len=52) 
12 1.687833 Sshanghai ”Sydney ssH Client: Encrypted packet (len=52) 
图 4 





延迟 确认 的 坏处 也 很 明显 ， 就 是 会 插 空 多 出 一 段 延迟 。 这 个 机 制 的 
作用 很 像 你 中 午 懒得 去 食 和 吃 饭 ， 便 等 到 下 午 出 门 上 谍 时 顺便 去 吃 一 
点 。 结 采 际 是 少 跑 了 一 趟 食管 ， 但 是 吃饭 时 间 却 梓 延 后 了 。 

理解 了 延迟 确认 的 原理 ， 我 们 再 回顾 VMware 的 那 篇 文章 。 一 般 来 
说 ， 侦 尔 浪费 200 肥 秒 的 等 等 时 间 并 不 算 严 重 的 问题 ，VMware 为 什么 要 
这 么 在 意 呢 ? 又 不 是 等 竺 很 多 个 200 毫 秒 。 当 我 联想 到 “很 多 个 ”时 ， 终 
于 明白 了 一 一 这 世界 上 还 真 的 存在 一 种 很 老 的 TCP 的 实现 RFC 
2582) ， 会 导致 拥塞 时 出 现 多 个 200 毫 秒 的 等 待 时 间 。 详 情 且 看 下 文 分 

















析 。 
图 5 从 客户 端的 视角 演示 了 局 用 延迟 确认 时 ， 某 些 TCP 协 议 栈 在 处 
理 网 络 拥塞 时 的 状况 。 


局 用 延迟 确认 







隅 200ms 


陋 200ms 


陋 200ms 


这 个 传输 过 程 发 生 了 以 下 事件 。 
1. 客户 病 在 同一 时 刻 ( 或 者 说 同一 窗口 ) 发 送 了 9 个 TCP 包 ， 其 中 


3、4、5 号 因为 拥 竖 丢失 了 。 

2. 到 达 服 务 器 的 6、7、8、9 号 包 触 用 了 4 个 “Ack 3”， 于 是 客户 端 
快速 重 传 3 号 包 ， 此 时 它 并 不 知道 4 号 包 也 丢 了 。 

3. 由 于 服务 器 上 局 用 了 延迟 确认 ， 所 以 它 收 到 3 号 包 之 后 ， 等 待 了 
200 曼 秒 才 回 复 Ack 4。 

4. 客户 端 重 传 4 号 包 ， 然 后 服务 器 又 等 待 了 200 坚 秒 才 回 复 Ack 5。 

5. 客户 端 重 传 5 号 包 ， 然 后 服务 器 又 等 待 了 200 坚 秒 才 回 复 Ack 
10。 

6. 客户 端 传输 新 的 10 号 包 ， 自 此 该 网 络 拥塞 就 完全 恢复 了 。 

由 于 当时 没有 抓 包 ， 因 此 以 上 分 析 仅 是 我 的 推出 。 还 有 另 一 种 可 能 
是 在 某 个 200 芝 秒 的 延迟 过 程 中 ， 那 些 丢 包 的 RTO (Retransmission 
Timeout) 已 经 被 触发 ， 所 以 进入 了 超时 重 传 阶段 。 无 论 符 合 哪 一 种 可 
能 ， 性 能 都 会 严重 下 降 ， 因 此 VMware ”建议 关闭 延迟 确认 是 很 有 道理 
的 ， 只 不 过 没 把 原理 说 清楚 。 我 甚至 怀疑 写 这 篇 文章 的 人 也 没 真正 理 
解 ， 因 为 里 面 还 提 到 了 慢 局 动 之 类 不 太 相 关 的 东西 。 

假如 把 延迟 确认 关闭 掉 ， 那 该 TCP 协 议 栈 处 理 拥塞 的 过 程 束 变 成 图 
6 所 示 。 包 还 是 那些 包 ， 不 过 浪费 在 延迟 确认 上 的 600 喀 秒 就 省 下 来 了 。 
只 要 往返 时 间 不 是 太 长 ， 那 些 丢 包 也 不 会 触发 超时 重 传 ， 所 以 避免 了 第 
二 种 可 能 。 

















我 把 分 析 结 


告诉 了 那 位 读者 ， 确 保 这 个 修改 没什么 副作用 。 于 是 





他 壮 着 胆子 关闭 了 延迟 确认 ， 果 然 YVMware 的 性 能 就 斋 升 了 。 图 7 是 他 在 
关闭 之 后 抓 的 网 络 包 ， 和 上 文 分 析 的 一 模 一 样 ， 果 然 连 续 丢 了 很 多 包 ， 
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Source 

Server 
Client 
Server 
Client 
Server 
Client 
SerVver 
Client 
Server 
Client 
Server 
Client 
Server 
Client 
Server 
Client 


Destination 
Client 
Server 
Client 
Server 
Client 
Server 
Client 
Server 
Client 
Server 
Client 
Server 
Client 
Server 
Client 
Server 


protocol Info 

TCP 3260-50481 [ACK] Seq=153777 Ack=99943465 Win=1024 Len=0 

TCP [continuation to #146418] [TCP Retransmission] 50481-3260 [ACK] Seq=99943465 
TCP 3260-~50481 [ACK] Seq=153777 Ack=99944925 Win=1024 Len=0 

TCP [continuation to #146418] [TCP Retransmission] 50481-3260 [ACK] seq=99944925 
TCP 3260-~50481 [ACK] Seq=153777 Ack=99946385 Win=1024 Len=0 

TCP [Continuation to #146418] [TCP Retransmission] 50481~3260 [ACK] Seq=99946385 
TCP 3260-50481 [ACK] seq=153777 Ack=99947845 Win=1024 Len=0 

TCP [Continuation to #146418] [TCP Retransmission] 50481-3260 [ACK] Seq=99947845 
TCP 3260-~50481 [ACK] Seq=153777 Ack=99949305 Win=1024 Len=0 

TCP [continuation to #146418] [TCP Retransmission] 50481-3260 [ACK] Seq=99949305 
WS 3260-~50481 [ACK] Seq=153777 Ack=99950765 Win=1024 Len=0 

TCP [Continuation to #146418] [TCP Retransmission] 50481-~3260 [ACK] Seq=99950765 
TCP 3260-~50481 [ACK] Seq=153777 Ack=99952225 Win=1024 Len=0 

TCP [continuation to #146418] [TCP Retransmission] 50481-~3260 [ACK] Seq=99952225 
TCP 3260-~50481 [ACK] Seq=153777 Ack=99953685 Win=1024 Len=0 

TCP [continuation to #146418] [TCP Retransmission] 50481-3260 [ACK] Seq=99953685 


图 7 


我 以 前 分 享 的 案例 都 是 先 在 Wireshark 中 找到 症状 ， 然 后 再 结合 协议 
分 析 找 到 原因 的 。 而 这 次 纯粹 是 依靠 协议 分 析 ， 预 测 能 从 包 里 看 到 什 
么 ， 然 后 再 用 Wireshark 验 证 的 。 上 听 起 来 似乎 是 完全 靠 灵 感 ， 但 灵感 不 是 
天 生 的 ， 它 来 自 长 期 的 训练 。 只 有 在 Wireshark 中 看 过 了 延迟 确认 和 大 量 
重 传 的 样子 ， 才 可 能 意识 到 它们 放 在 一 起 会 出 大 问题 。 


注意 : 如 果 对 那 篇 VMware 的 文章 感 兴趣 ， 可 以 在 其 知识 库 http:/kb.vmware.com 中 搜索 














1002598 来 找到 它 。 





前 一 篇 文章 发 布 后 ， 被 一 些 公众 号 转发 了 。 于 是 就 有 资深 技术 人 员 
找到 我 ， 说 读 完 觉 得 不 过 关 ， 希 望 来 点 有 深度 的 。 好 吧 ， 那 篇 的 确 只 从 
表面 上 介绍 了 延迟 确认 在 网 络 发 生 拥塞 时 的 影响 ， 要 往 深 处 分 析 的 话 还 
是 有 不 少 料 的 。 

先 发 散 一 下 思维 : 除了 VMware 所 建议 的 关闭 延迟 确认 ， 还 有 其 他 
的 方法 可 以 解决 这 个 问题 吗 ? 

答案 是 肯定 的 。 既 然 VMware 的 文章 说 “ 某 些 提供 iSCSI 访问 的 存储 
阵列 在 出 现 网 络 拥塞 时 处 理 不 当 ”， 就 说 明 还 有 些 存 储 阵列 是 处 理 得 当 
的 ， 即 使 打开 延迟 确认 也 不 怕 。 那 它们 又 是 如 何 处 理 的 呢 ? 我 做 了 很 多 
研究 之 后 ， 发 现 它们 其 实 束 是 启用 了 TCP SACK (Selective 
Acknowledgement) 功能 ， 因 此 在 大 量 丢 包 的 时 候 不 需要 每 个 重 传 包 都 
确认 一 次 ， 也 就 不 怕 延 迟 确 认 的 影响 了 。 几 1 从 客户 端的 角度 演示 了 同 
样 丢 包 的 情况 下 ， 启 用 SACK 的 TCP 协 议 栈 是 怎样 处 理 重 传 的 。 
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图 1 

这 个 传输 过 程 发 生 了 以 下 事件 。 

1. 客户 端 在 同一 时 刻 《〈 或 者 说 同一 窗口 ) 发 送 了 9 个 TCP 包 ， 其 中 
3、4、5 号 因为 拥塞 丢失 了 。 

2. 到 达 服 务 器 的 6、7、8、9 号 包 触 发 了 4 个 “Ack 3”。 

3. 由 于 启用 了 SACK， 所 以 服务 器 可 以 在 4 个 “Ack 3? 中 告知 客户 端 
哪些 包 已 经 收 到 了 。 

4. 因为 客户 端 已 经 知道 哪些 包 丢 了 ， 哪 些 包 已 经 收 到 ， 所 以 它 可 
以 一 口气 完成 重 传 。 

SACK 信 息 在 Wireshark 中 很 容易 看 到 。 如 图 2 所 示 ， 只 要 
把 “Ack=656925” 和 “SACK: 661857-663035” 这 两 个 因素 结合 起 来 ， 客 户 


端 就 知道 排 在 后 面 的 数据 段 661857-663035 已 经 送 达 ， 但 排 在 前 面 的 
656925-661856 〈 共 4932 字 节 ) 反而 丢失 了 ， 因 此 它 需 要 重 传 这 上 段 数 
据 。 从 图 3 可 以 看 到 每 个 重 传 包 的 Len 值 ， 四 个 包 加 起 来 恰好 就 等 于 4932 
字 节 。 


824 4.472656 Server Client TCP [TCP Dup ACK 821#1] 8888-60479 [ACK] Seq=829 Ack=656925 


Mh 














习 SACK: 661857-663035 
Kind: SACK (5) 
Length: 10 
left edge = 661857 (relative) 
right edge = 663035 (relative) 








图 2 
No， Tim Source Destination Protocol Info 
825 4. 47 2656 Client SerVver TCP [TCP Retransmission] 60479-~8888 [ACK] Seq=656925 Ack=829 Win=48363 Len=1388 
874 4.531250 Client Server TCP [TcP Retransmission] 60479-~8888 [ACK] Seq=658313 Ack=829 Win=48363 Len=1388 
876 4.535156 Client Server TCP [TCP Retransmission] 60479-~8888 [ACK] Seq=659701 Ack=829 Win=48363 Len=1388 
878 4.535156 Client Server TCP [TCP Retransmission] 60479-~8888 [ACK] Seq=661089 Ack=829 Win=48363 Len=768 


图 3 

由 此 可 见 启 用 SACK 其 实 比 关 闭 延 迟 确 认 更 高 效 ， 因 为 它 可 以 一 次 
性 重 传 多 个 丢 包 ， 而 不 用 每 重 传 一 个 就 等 待 一 次 Ack， 上 日 费 多 个 往返 机 
间 。 这 在 局 域 网 环境 中 的 优势 还 不 太 明 显 ， 如 果 是 在 远程 镜像 中 ， 一 
正常 的 往返 时 间 都 要 花 上 百 喀 秒 ， 那 就 更 应 该 启用 SACK 了 。 我 真 的 很 
好 奇 VMware 为 什么 不 提供 这 个 建议 。 

说 完 SACK， 再 讲 一 个 更 加 有 深度 的 知识 点 : 除了 大 量 重 传 之 外 ， 
延迟 确认 还 会 在 什么 场景 下 严重 影响 性 能 ? 

从 本 质 上 上 看， 延迟 确认 之 所 以 会 在 大 量 重 传 时 影响 性 能 ， 是 因为 它 
在 该 场景 下 会 多 次 出 现 〈 甚 至 因为 延迟 太 和 久 而 导 致 超时 重 传 ) 。 那 么 
有 什么 场景 会 导致 延迟 确认 多 次 出 现 呢 ? 凭空 想象 是 很 难得 到 答案 的 ， 
不 过 当 你 看 过 的 网 络 包 足够 多 时 ， 表 定 会 过 到 一 些 。 我 个 人 过 到 最 多 的 
是 TCP 窗 口 极 小 的 情况 ， 此 时 启用 延 运 确认 简直 束 是 雪上 上 加害 。 图 4 演 
示 了 服务 器 接收 窗口 只 有 2920 字 节 (相当 于 两 个 MSS)， ， 且 关闭 了 延迟 
确认 时 的 场景 。 因 为 客户 端 每 发 两 个 包 束 会 耗 光 窗 口 ， 所 以 不 得 不 停 下 
来 等 待 服务 器 的 确认 。 假 如 这 时 候 在 服务 器 上 局 用 了 延迟 确认 ， 那 29 号 
和 30 号 之 间 、32 号 与 33 号 之 间 .……. 以 及 38 号 和 39 号 之 间 都 需要 多 等 符 





SF 














200 坚 秒 ， 意 味 着 传输 效率 会 下 降 数 日 倍 。 这 个 场景 下 的 延迟 确认 杀伤 
力 巨 大 ， 又 非常 隐蔽 ， 所 以 第 一 次 遇 上 的 工程 师 根 本 不 知 所 措 。 





No. _ Time Source Destination Protocol Info 
28 1.256466 Client Server TCP [Continuation to #26] 445-2199 [ACK] Seq=2545 Ack=885 Win=65535 Len=1448 
29 1.256474 Client server TCP [Continuation to #26] 445-2199 [ACK] Seq=3993 Ack=885 Win=65535 Len=1448 
30 1.256483 server Client TCP 2199-445 [ACK] Seq=885 Ack=5441 Win=2920 Len=0 TSval=27476 TSecr=378779 
31 1.256714 Client Server TCP [Continuation to #26] 445-2199 [ACK] Seq=5441 Ack=885 Win=65535 Len=1448 
32 1.256720 client server TCP [Continuation to #26] 445-2199 [ACK] Seq=6889 Ack=885 Win=65535 Len=1448 
33 1.256729 server Client TCP 2199-~445 [ACK] Seq=885 Ack=8337 Win=2920 Len=0 TSval=27476 TSecr=378779 
34 1.256948 Client server TCP [Continuation to #26] 445-2199 [ACK] Seq=8337 Ack=885 Win=65535 Len=1448 - 
35 1.256953 Client Server TCP [Continuation to #26] 445-2199 [ACK] Seq=9785 Ack=885 Win=65535 Len=1448 
36 1.256961 server Client TCP 2199-445 [ACK] Seq=885 Ack=11233 Win=2920 Len=0 TSval=27476 TSecr=378779 
37 1.257191 Client server TCP [Continuation to #26] 445-2199 [ACK] Seq=11233 Ack=885 Win=65535 Len=1448 
38 1.257201 Client server TCP [Continuation to #26] 445-2199 [ACK] Seq=12681 Ack=885 Win=65535 Len=1448 
39 1.257208 server Client TCP 2199-445 [ACK] Seq=885 Ack=l4129 Win=2920 Len=0 TSval=27476 TSecr=378779 


图 4 

其 他 的 场景 我 也 过 到 过 一 些 ， 不 过 次 数 很 少 ， 就 不 一 一 列举 了 。 更 
值得 关注 的 ， 是 如 何在 Wireshark 中 发 现 延 人 运 确 认 ， 并 计算 它 所 带 来 的 影 
啊 。 

由 于 延迟 确认 是 一 个 正常 的 TCP 机 制 ， 有 其 积极 的 一 面 ， 所 以 
Wireshark 是 不 会 把 它 当 作 问 题 标 志 出 来 的 ， 而 且 点 击 Analyze ~ Expert 
Info 菜 单 也 是 不 会 统计 延迟 确认 的 。 难 道 我 们 只 能 靠 人 工 去 计算 每 个 确 
认 包 的 等 待 时 间 吗 ? 我 几 年 前 就 因此 吃 过 一 次 亏 一 一 有 位 同事 找 我 分 析 
一 个 性 能 相关 的 网 络 包 ， 我 用 “Wireshark 看 了 半天 都 没有 发 现 问题 ， 所 
以 就 斩钉截铁 地 说 跟 网 络 无 关 。 后 来 客户 目 己 尝试 关闭 了 延迟 确认 ， 人 性 
能 居然 就 岂 升 了 ， 导 致 我 和 同事 都 非常 尴 众 。 最 后 写 分 析 报 告 的 时 候 才 
想到 办 法 : 只 要 用 “tcp.analysis.ack_rtt>0.2and ”tcp.len==0” 过 滤 一 下 ， 就 
可 以 把 所 有 超过 200 写 秒 的 确认 都 科 出 来 了 “当然 得 出 来 的 不 一 定 全 都 
是 延迟 确认 ， 奶 求 精确 的 话 就 逐个 检查 ) 。 图 5 正 是 我 当年 遇 到 的 那个 
网 络 包 ， 只 要 把 过 小 出 来 的 包 数 乘 以 0.2 秒 ， 束 知道 大 概 浪 费 了 多 少时 
间 。 











Filter | tcp.analysis.ack_rtt >0.2 and tcp.len==0 [>| Expression.. Clear Apply Save 


No. Time Source Destination Protocol Info 
6079 121.946662 Sserver Client TCP 3260~34356 [ACK] Seq=71983377 Ack=191109997 Win=24576 Len=0 
6085 122.346677 Server Client TCP 3260-34356 [ACK] Seq=71983425 Ack=191202769 Win=24576 Len=0 
6099 122.746720 server Client TCP 3260-34356 [ACK] Seq=71983425 Ack=191264617 Win=24576 Len=0 
6221 124.946945 server Client TCP 3260-34356 [ACK] Seq=102185617 Ack=197965957 Win=24576 Len=0 
6226 125.347023 Sserver Client TCP 3260-34356 [ACK] seq=102185617 Ack=197994989 Win=24576 Len=0 
6257 125.747026 Sserver Client Ter 3260-34356 [ACK] Seq=102186049 Ack=198074809 Win=24576 Len=0 
6273 126.547094 server Client TCP 3260-34356 [ACK] Seq=102186049 Ack=198144457 Win=24576 Len=0 


图 5 





这 两 篇 文章 所 列举 的 案例 ， 其 实在 现实 环境 中 广泛 存在 。 不 过 由 于 
证 状 只 是 性 能 关 ， 所 以 很 多 用 户 以 为 是 带 视 不 足 导 致 的 ， 融 一 直 各 着 。 
用 Wireshark 抓 个 包 看 看 吧 ， 很 可 能 无 需 升 级 硬件 ， 也 可 以 帮 你 的 系统 大 
幅度 提升 性 能 的 。 





我 原本 以 为 TCP 三 次 握手 不 值得 写 ， 没 想到 在 某 技术 社区 上 被 提问 
好 几 次 了 。 看 来 感 兴趣 的 人 还 真 不 少 ， 还 是 写 一 篇 吧 。 
我 们 知道 TCP 需 要 通过 三 次 握手 来 建 并 连接， 过 程 如 图 1 所 示 。 





图 1 





从 Wireshark 上 看 到 的 握手 过 程 束 是 图 2 这 样 的 ， 你 可 以 把 Seq 和 号 和 








mA 三 网 m 人 
Ack 写 代入 图 1 中 ， 看 看 是 人 否 符 合 规 律 。 
No, Time Source Destination Protocol Info 

1 0.000000 Client server TCP 54395-8888 
2 0.007812 Server Client TCP 8888-534395 
3 0.007812 Client Server TCP 54395~8888 


图 2 
当 X 和 Y 的 值 太 大 时 ， 看 起 来 就 不 太 友好 ， 尤 其 是 需要 对 这 些 号 码 
做 加 减 运 算 时 。 于 是 Wireshark 提 供 了 一 个 功能 把 Seq 和 Ack 的 初始 
值 都 置 成 09， 即 用 “相对 值 ” 来 代 蔡 “真实 值 >?。 我 们 可 以 在 











SYN|] seq=27714969641| Win=65535 Len=0 MSS= 
SYN, ACK] seq=3290646529 Ack=2771496962 
ACK] Seg=2771496962 Ack=3290646530| Win=1 












Edit Preferences -, Protocols ,“TCP 荣 单 中 勾 上 Relative Sequence 
Numbers 来 启用 它 。 启 用 之 后 ， 图 2 的 包 就 变 成 图 3 这 样 ， 是 不 是 清 严 了 
很 多 ? 

No. Time Source Destination Protocol Info 










Win=65535 Len=0 | 
SYN, ACK] Seg=0 ACck=1 Win=6 
ACK] Seg=1 Ack=1|win=139264 


1 0.000000 Client server TCP S4395--8888 
2 0.007812 Server Client TCP BB88-54395 
| 3 0.007812 client server TCcP 54395-8888 


图 3 

成 功 的 握手 都 是 一 样 的 ， 失 败 的 握手 却 各 有 不 同 ， 因 此 解决 起 来 还 
是 需要 一 些 技巧 的 。 当 我 们 遭遇 TCP 连 接 建 立 失 败 时 ， 最 稳当 的 排查 方 
式 就 是 用 Wireshark 来 分 析 。 网 络 包 不 多 的 时 候 很 容易 入 手 ， 用 肉眼 观察 
就 行 ， 但 如 果 抓 到 的 包 特 别 大 就 需要 过 滤 技 巧 了 。 根 据 我 的 经 验 ， 握 手 
失败 一 般 分 两 种 类 型 ， 要 么 被 拒绝 ， 要 么 是 丢 包 了 。 因 此 用 两 道 过 滤 表 
达 式 惑 可 以 定位 出 大 多 数 失败 的 握手 。 

表达 式 1: (tcp.flags.reset==1)& & (tcp.sed==1) 

从 表面 上 看 ， 它 只 是 过 滤 出 Seq 号 为 1， 且 含有 Reset 标 志 的 包 ， 似 
乎 与 握手 无 关 。 但 在 启用 Relative _ Sequence Numbers 的 情况 下 ， 这 往往 
表示 握手 请 求 被 对 方 拒 绝 了 ， 结 果 如 图 4 所 示 。 接 下 来 只 需 右键 选中 过 
滤 出 的 包 ， 再 点 击 Follow TCP Stream 就 可 以 把 失败 的 全 过 程 显 示 出 来 ， 
见 图 5。 此 次 握手 失败 的 原因 是 服务 器 没有 在 监听 80 端 口 ， 所 以 拒绝 了 
客户 问 的 握手 请 求 。 

















Filter: | (tcp.flags.reset == 1) && (tcp.seq == 1) =| Expression... Clear Apply Save 


No,. Time Source Destination Protocol Info 


26 1.734347 Sserver Client TCP O00T73 EnsT, ACK] Som < 
| Mark Packet (toggle) 


lgnore Packet (toggle) 
| @ Set Time Reference (toggle) 
© Time Shift... 

Edit Packet 


| 闭 Packet Comment... 
Manually Resolve Address 


Apply as Filter 
Prepare a Filter 
Conversation Filter 
Colorize Conversation 
SCTP 


Follow TCP Stream 


oh 





图 4 
Filter: | tcp.stream eq 5 [> | Expression.. Clear Apply Save 


No, Time Source Destination Protocol Info 
25 1.734177 Client server TCP 60173~80 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 
26 1.734347 Server Client TCP 80-~60173 [RST, ACK] Seq=1 Ack=l Win=0 Len=0 


图 5 
表达 式 2: (tcp.flags.syn==1)& & (tcp.analysis.retransmission) 
这 道 表 达 式 可 以 过 滤 出 重 传 的 握手 请 求 。 一 个 握手 请 求 之 所 以 要 重 
传 ， 往 往 是 因为 对 方 没收 到 ， 或 者 对 方 回 复 的 确认 包 丢 失 了 。 这 个 重 传 
特征 正好 用 来 过 滤 ， 结 果 如 图 6 所 示 。 接 下 来 右键 点 击 过 滤 出 的 包 ， 再 
用 Follow TCP Stream 就 可 以 把 失败 过 程 显示 出 来 ， 见 图 7。 此 次 握手 失 
败 的 原因 是 丢 包 ， 上 所 以 服务 器 收 不 到 握手 请 求 。 














Filter | (tcp.flags.syn == 1) && (tcp.analysis.retransmission) [| Expression... Clear Apply Save 





No. Time Source Destination Protocol Info 
847 28.921799 Client server TCP [TCP Retransmission] 38957-5040 [SYN] Seq=0 Win= 
1020 34.937546 Client Server TCP [TCP Retransmission] 38957-504A—CeYN < 一 -vs 一 
Mark Packet (toggle) 
lgnore Packet (toggle) 
© Set Time Reference (tc 
© Time Shift... 
Edit Packet 
阅 Packet Comment.,, 
Manually Resolve Add 
Apply as Filter 
Prepare a Filter 
Conversation Filter 
Colorize Conversation 
SCTP 
Follow TCP Stream 
图 6 
Filter: | tcp.stream eq 1 [>| Expression.. Clear Apply Save 
No. Time Source Destination Protocol Info 
765 25.914925 Client server TCP 38957~5040 [SYN] Seq=0 Win=14480 Len=0 MSS=1460 SACK_I 
847 28.921799 Client server TCP [TCP Retransmission] 38957~5040 [SYN] seq=0 Win=14480 
1020 34.937546 Client server TCP [TCP Retransmission] 38957~5040 [SYN] seq=0 Win=14480 
图 7 


这 两 个 表达 式 很 好 用 ， 不 过 要 最 快 排查 出 根本 原因 还 需要 男 一 个 技 
巧 ， 即 在 两 端 同 时 抓 包 来 分 析 。 为 什么 要 两 端 同时 抓 呢 ? 请 考虑 图 8 所 
示 的 两 种 状况 。 

TCP 三 次 握手 失败 TCP 三 次 握手 失败 


SYY seg。y 


丢 包 





客户 端 服务 器 客户 端 服务 器 
图 8 


同样 是 握手 失败 ， 左 图 是 客户 端 发 出 的 包 丢 了 ， 石 图 则 是 服务 器 回 
复 的 包 丢 了 。 不 同 的 丢 包 往往 意味 着 不 同 的 问题 根源 ， 解 决 方式 也 不 一 
样 。 如 果 只 在 客户 站 抓 包 ， 那 这 两 种 丢 包 的 症状 看 起 来 就 像 是 一 样 的 ， 
排查 起 来 也 会 慢 一 些 。 





说 完 握手 失败 的 排 但 技巧 ， 我 们 再 来 讲 讲 和 握手 有 关 的 安全 问题 。 


做 运 维 的 工程 师 们 都 知道 ， 大 规模 DDoS (Distributed 


Denial 


of 


Service， 分 布 式 拒绝 服务 攻击 ) 来临 的 时 候 最 惊 心 动 物 。DDoS 的 形式 
有 很 多 种 ， 其 中 最 流行 的 就 是 基于 三 次 握手 的 SYN flood， 其 原理 是 从 
大 量 主机 发 送 SYN 请 求 给 服务 器 ， 假 装 要 建立 TCP 连 接 。 这 些 SYN 请 求 
可 能 含有 假 的 源 地 址 ， 所 以 服务 器 响应 后 永远 收 不 到 Ack， 就 会 留 下 
half-open 状 态 的 TCP 连 接 。 由 于 每 个 TCP 连 接 都 会 消耗 一 定 的 系统 资 


源 ， 如 果 攻 击 足 够 猛 
光 ， 真 正 的 用 户 访问 也 会 被 拒绝 。 


列 


EE 





此 类 连接 越 建 越 多 ， 服 务 需 的 资源 融会 被 耗 


Wireshark 可 以 轻易 地 发 现 SYN _ flood。 有 时 一 打开 包 就 很 显眼 了 ， 





如 图 9 所 示 ， 密 密 麻 麻 都 是 SYN。 假 如 干扰 包 太 多 ， 那 就 点 击 
Analyze Expert Info -, Chats 菜 单 ， 可 以 看 到 SYN 的 总 数量 统计 。 
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13 0.005790000 
14 0.006253000 
15 0.006705000 
16 0.007177000 
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图 9 
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我 们 可 以 把 SYN flood 看 作 TCP 协 议 的 设计 缺陷 ， 有 办 法 可 以 防御 ， 
却 无 法 根除 。 想 知道 大 公司 都 是 怎样 防御 的 吗 ? 手段 有 很 多 ， 其 中 有 一 
些 还 可 以 在 Wireshark 中 看 出 端倪 。 我 假装 攻击 了 全 球 最 大 的 假 药 销售 网 
站 ， 然 后 把 全 过 程 的 包 抓 下 来 。 从 图 10 可 见 ， 对 方 很 快 就 识别 了 我 的 不 
民 音 图， 所 以 Reset (RST) 了 大 多 数 握 手 请 求 。 如 果 有 兴趣 去 研究 RST 
包 里 的 细节 ， 比 如 网 络 层 的 TIL 和 Identification， 也 许 还 能 判断 出 究竟 





是 流量 清洗 还 是 TCP 握 手 代 理 之 类 的 。 本 书 不 是 网 络 安全 专著 ， 所 以 就 
不 展开 分 析 了 。 
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人 一 旦 形成 某 种 思维 定 势 ， 就 很 难 再 改变 了 。 知 道 我 收 到 最 多 的 读 
者 来 信和 是 问 什 么 吗 ?“ 林 工 ， 有 些 TCP 包 发 出 去 之 后 没有 看 到 对 应 的 
Ack， 算 不 算 丢 包 啊 ? ”这 个 问题 让 我 很 是 好 奇 ， 明 明 RFC 上 没有 这 样 的 
规定 ， 为 什么 总 有 读者 觉得 每 一 个 数据 包 都 应 该 有 对 应 的 Ack 呢 ? 后 来 
才 注 意 到 ， 很 多 提问 者 是 做 网 站 开发 出 身 的 ， 已 经 习惯 了 每 个 HTTP 请 
求 发 出 去 ， 就 一 定 会 收 到 一 个 HTTP 响 应 〈 见 图 1) ， 因 此 就 把 这 个 模式 
套 到 了 TCP 上 。 其 实 不 止 HITP， 绝 大 多 数 应 用 层 协 议 都 采用 这 种 一 问 
一 答 的 工作 方式 。 

















Filter http -| Expression... Clear Apply Save 
No, Time Source Destination Protocol Info 
4 0.006080000 Client Web_server HTTP GET /woriginal/70398db5jwlepzpi0g292j20xc1i8gdo8. 
243 0.632784000 Web_server Client HTTP HTTP/1.1 200 OK (JPEG JFIF image) 
245 4.956797000 Client Web_server HTTP GET /Narge/70398db5jwlepzpi0g292j20xcl8gdo8. jpg 
687 6.202698000 Web_server Client HTTP HTTP/1.1 200 OK (JPEG JFIF image) 
图 1 


TCP 当 然 也 可 以 采用 这 种 方式 ， 但 并 非 必要 。 惑 像 我 们 不 用 每 天 都 
跟 公司 算 一 次 工钱 ， 而 是 揭 到 月 撒 结 算 一 样 ， 数 据 接 收 方 也 可 以 累积 
些 包 才 对 发 送 方 Ack 一 次 。 至 于 Ack 的 频率 ， 不 同 的 操作 系统 有 不 同 的 
偏好 ， 比 如 我 实验 室 中 的 Linux 客 户 端 喜欢 每 收 到 两 个 包 Ack 一 次 ， 见 图 
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No. Time Source Destination Protocol Info 
34 15.404708 Server Linux_Client TCP [Continuation to #16] 2049-703 [ACK] Seq=18549 Ack=873 
35 15.404939 Server Linux_Client TCP [Continuation to #16] 2049-703 [ACK] Seq=19997 Ack=873 
36 15.404948 Linux_Client Server TCP 703-2049 [ACK] Seq=873 Ack=21445 Win=1567 Len=0 TSval= 
37 15.404957 Server Linux_Client TCP [Continuation to #16] 2049-703 [ACK] Seq=21445 Ack=873 
38 15.405187 Server Linux_Client TCP [Continuation to #16] 2049-703 [ACK] Seq=22893 Ack=873 
39 15.405193 Linux_Client Server TCP 703-2049 [ACK] Seq=873 Ack=24341 Win=1748 Len=0 TSval= 
40 15.405197 server Linux_Client TCP [Continuation to #16] 2049-703 [ACK] Seq=24341 Ack=873 
41 15.405438 Server Linux_Client TCP [Continuation to #16] 2049-703 [ACK] Seq=25789 Ack=873 
42 15.405445 Linux_Client Server TCP 703-2049 [ACK] Seq=873 Ack=27237 Win=1929 Len=0 TSval= 





图 2 
而 Windows 客 户 端 则 懒得 多 ， 隔 好 多 个 包 才 Ack 一 次 ， 见 图 3 的 97 号 





No. Time Source Destination Protocol Info 
86 2.998921 Sserver Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=49993 Ack=1964 
87 2.998922 server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=51421 Ack=1964 
88 2.998924 Sserver Windows_Client TCP [Continuation to #73] 445-64944 [ACK] seq=52849 Ack=1964 
89 2.998926 server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=54277 Ack=1964 
90 2.998927 server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=55705 Ack=1964 
91 2.998929 server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=57133 Ack=1964 
92 2.998930 Sserver Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=58561 Ack=1964 
93 2.998932 Sserver Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=59989 Ack=1964 
94 2.998933 server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=61417 Ack=1964 
95 2.998943 Sserver Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=62845 Ack=1964 
96 2.998944 Server Windows_Client TCP [Continuation to #73] 445-64944 [ACK] Seq=64273 Ack=1964 
97 2.998960 Windows_Client server TCP 64944-445 [ACK] Seq=2027 Ack=65701 Win=256 Len=0 
图 3 











这 两 种 方式 都 是 正常 的 ， 但 Linux 对 流量 更 “大 手 大 脚 ”一 点 ， 因 为 
纯 Ack 也 算 流 量 的 。 其 实在 网 络 带宽 越 来 越 大 的 今天 ， 人 们 已 经 不 在 乎 
这 种 小 流量 了 。 不 过 手机 操作 系统 还 是 要 慎重 考虑 的 ， 毕 苋 蜂 负数 据 是 
按 流 量 计 费 的 ， 能 省 一 点 是 一 点 。 我 的 安 日 手机 就 是 每 收 到 一 个 包 都 会 
Ack 的 ， 想 到 这 里 我 的 心 都 在 滴 血 。 图 4 是 我 在 微 博 上 打开 一 张 美女 图 时 
产生 的 流量 ， 你 看 这 些 密密麻麻 的 纯 Ack， 每 个 都 日 费 我 40 字 节 的 流 
量 。 

Source Destination Protocol Info 

.571283000 Client Web_server 51030-80 [ACK] Seq=2298005100 Ack=50025943 Win=45440 Len=0 

.571453000 Client Web_server 51030~80 [ACK] Seq=2298005100 Ack=50027343 Win=48256 Len=0 

.571653000 Client Web_server 51030~80 [ACK] Seq=2298005100 Ack=50028743 Win=51072 Len=0 


.573684000 Client Web_server 51030-80 [ACK] seq=2298005100 Ack=50030143 Win=53888 Len=0 
.573906000 Client Web_server 51030-80 [ACK] Seq=2298005100 Ack=50031543 Win=56704 Len=0 


.574070000 Client Web_server 51030-80 [ACK] Seq=2298005100 Ack=50032943 Win=59520 Len=0 
.574228000 Client Web_server 51030-80 [ACK] Seq=2298005100 Ack=50034343 Win=62208 Len=0 
.574401000 Client Web_server 51030~80 [ACK] Seq=2298005100 Ack=50035743 Win=65024 Len=0 
.574572000 Client Web_server 51030~80 [ACK] Seq=2298005100 Ack=50037143 Win=67840 Len=0 
.574730000 Client Web_server 51030~80 [ACK] Seq=2298005100 Ack=50038543 Win=70656 Len=0 
.574885000 Client Web_server 51030-80 [ACK] Seq=2298005100 Ack=50039943 Win=73472 Len=0 





图 4 

也 许 以 后 会 有 手机 厂商 优化 它 ， 然 后 以 此 作为 卖点 。 如 果 是 从 我 这 
本 书 里 学 到 的 ， 请 为 它 命名 “ 林 妇 台 算 法 ”。 

既然 接收 方 不 一 定 收 到 每 个 包 都 要 Ack， 那 发 送 方 怎么 知道 哪些 包 
虽然 没有 相应 的 Ack， 但 其 实 已 经 送 达 了 呢 ? 记 住 ，Ack 是 有 累积 效应 
的 ， 它 隐 含 了 “在 此 之 前 的 其 他 包 也 已 收 到 ”的 意思 ， 比 如 图 3 中 第 97 号 
包 的 Ack 二 65701 不 仪表 示 收 到 了 96 写 包 ( 其 
Seq+Len=64273+1428=65701) ， 而 且 上 暗示 之 前 的 其 他 包 也 都 收 到 了 。 
因此 86 一 95 号 包 虽 然 没 有 被 显 式 Ack， 但 发 送 方 知道 它们 也 已 经 被 送 达 
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另 一 个 对 TCP 的 广泛 误解 则 和 UDP 相关 。 有 不 少 技术 人 员 认 为 TCP 
的 效率 低 ， 因 为 其 传输 过 程 中 需要 往返 时 间 来 确认 〈Ack) 。 而 UDP 无 
需 确认 ， 因 此 能 不 停 地 发 包 ， 效 率 了 就 高 了 。 事 实 真 的 如 此 吗 ? 这 其 实 是 
对 TCP 传 输 机 制 的 严重 误解 。 我 们 可 以 假设 一 个 场景 来 类 比 TCP 的 工作 
方式 : 有 大 批 货物 要 从 A 地 运往 B 地 。 如 果 只 用 一 辆 货车 来 运 的 话 ， 马 
路 上 就 只 有 一 辆 车 在 来 回 跑 ( 回 程 相当 于 TCP 的 Ack 包 ) ， 效 率 确 实 很 
低 ， 对 TCP 的 误解 可 能 也 出 自 这 个 原因 。 但 如 果 在 不 塞车 的 前 提 下 尽量 
增加 货车 数量 ， 使 整 条 马路 上 充满 车 ， 总 传输 效率 就 提高 了 。TCP 友 送 
窗口 的 意义 相当 于 货车 的 数量 ， 只 要 窗口 足够 大 ，TCP 也 可 以 不 受 往 返 
时 间 的 约束 而 源源 不 断 地 传 数据 。 这 就 是 为 什么 无 论 在 局 域 网 还 是 广 域 
网 ，TCP 还 是 最 受 欢迎 的 传输 层 协议 。 

当然 TCP 确 实 也 有 因为 往返 时 间 而 降低 效率 的 时 候 ， 比 如 在 传输 小 
块 数据 的 场景 。 本 来 能 在 1 个 往返 时 间 完 成 的 小 事 ， 却 要 额外 耗费 3 次 握 
手 和 4 次 挥手 的 开销 ，DNS 碍 询 束 符合 这 种 场景 。 目 前 HTTP 基本 建立 在 
TCP 连 接 上 ， 所 以 也 会 因为 TCP 的 三 次 握手 而 增加 延迟 。 你 可 能 听 说 过 
Google 发 布 的 QUIC (Quick UDP Internet Connection) 协议 ， 它 就 是 为 
了 消除 TCP 的 延迟 而 设计 的 代 蔡 品 。 在 某 些 领域 可 以 视 为 TCP 的 竞争 对 
手 ， 目 前 在 Google 的 网 站 上 已 经 可 以 试用 了 。 




















这 也 许 称 得 上 最 经 典 的 网 络 问 题 ， 很 多 大 师 从 理论 上 分 析 过 的 ， 我 
能 在 现实 中 遇 到 也 算 三 生 有 幸 。 

事情 是 这 样 的 。 有 家 公司 来 咨询 一 个 性 能 问题 ， 说 是 从 AIX 备 份 数 
据 到 Windows 极 其 缓慢 ， 只 有 1MB/s， 备 份 所 用 的 协议 是 SFTP。 我 的 第 
一 反应 就 是 抓 个 包 ， 然 后 试 试 Wireshark 的 性 能 三 板 耸 。 

1. 从 Statistics ~ Summary 菜 单 可 见 ， 平 均 速 度 是 11 Mbit/s， 的 确 只 
比 1MB/s 高 一 些 ， 见 图 1。 


Ee 2— dS 


Traffic 4 Captured 4 Displayed 4 Displayed % 4 Marked 4 Mlarked 3% 4 
Packets 304 813 89.934 5 0 0.000% 





Between first and last packet 08l2 sec 0.812 sec 
Avg. packets/sec 1112.723 1000.713 


Awg, packet size 1238 bytes 1371 bytes 

Bytes 1119304 1114366 99.559% 
Avg. bytes/sec 1377738.740 1371660.611 

Avg, MBit/sec 11.022 10.973 


图 1 


2. 从 Analyze Expert ”Infos 沫 单 看 ， 网 络 状 况 堪 称 完美 。 请 看 图 
2， 连 一 个 warnings 和 Notes 都 没有 。 这 样 的 网 络 性 能 怎么 会 差 ? 











通 Wireshark 0 Expert Infos 
as 0 





Limit to display filter 











3. 选 定 一 个 从 AIX 发 往 Windows 的 包 ， 然 后 点 击 Statistics -, TCP 
StreamGraph -TCP Sequence Graph (Stevens) 菜单 ， 从 图 3 可 见 ， 这 60 
秒 中 数据 传输 得 很 均匀 ， 没 有 TCP Zero Window 或 者 死机 导致 的 暂停 。 





number[B] Time/Sequence Graph (Stevens) 


50000000 


40000000 


30000000 


20000000 


10000000 | 














图 3 

试 完 三 板 佐 ， 我 们 只 能 得 到 一 个 结论 备份 的 确 进行 得 很 慢 ， 但 是 
仅 赁 Wireshark 上 自 带 的 分 析 工 具 找 不 出 根本 原因 ， 这 也 许 意 味 着 问题 不 在 
网 络 上 ， 而 是 在 接收 方 或 者 发 送 方 上 。 幸 好 Wireshatk 不 但 能 发 现 网 络 上 
的 问题 ， 也 能 反映 出 接收 方 和 发 送 方 的 一 些 配 置 ， 只 是 需要 一 些 技巧 来 
发 现 。 

因为 数据 是 从 AIX 备 份 到 Windows 的 ， 所 以 如 果 把 SFTP (SSH File 
Transfer ”Protocol) 包 过 滤 出 来 ， 理 论 上 应 该 看 到 大 多 数 时 间 花 在 了 从 
AIX 到 Windows 的 传输 上 。 可 是 由 图 4 发 现 ， 从 AIX 到 Windows 的 包 虽 然 
占 多 数 ， 但 没 花 多 少时 间 。 反 而 从 Windows 到 AIX 的 两 个 包 〈533 和 
535) 之 间 竟 然 隔 了 0.2 秒 。 该 现象 在 整个 传输 过 程 中 出 现 得 很 频繁， 说 
不 定性 能 差 的 原因 就 在 此 处 了 。 只 要 把 根本 原因 找 出 来 ， 就 有 希望 解决 





























问题 。 


Fiter 


No. 
524 
525 
526 
527 
529 
530 
531 
533 
535 
536 
537 
538 
540 
541 
542 
543 
544 





图 5 所 示 的 包 。 可 见 Windows 发 出 533 号 包 之 后 就 停 下 


ssh 


Time 


0. 


411714000 


0.411714000 


品 口 口 口 口 口 口 口 口 口 口 口 口 口 口 


.411714000 
.411715000 
.411836000 
.411837000 
.411838000 
.412387000 
.606583000 
.606780000 
.606856000 
.606858000 
.606985000 
.606987000 
.606987000 
.606988000 
.606989000 


Source Destination 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
Windows AIX 

Windows AIX 

AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 
AIX Windows 


-| Expression... Clear Apply Save 
Protocol Info 
SSH server: Encrypted packet (len=1460) 
SSH server: Encrypted packet (len=1460) 
SSH server: Encrypted packet (len=940) 
SSH server : Encrypted packet (len=1460) 
SSH server: Encrypted packet (len=1460) 
SSH server: Encrypted packet (len=1460) 
ssH server: Encrypted packet (len=756) 
SSH Client: Encrypted packet (len=96) 
SSH Client: Encrypted packet (len=656) 
SSH server: Encrypted packet (len=1460) 
SSH server: Encrypted packet (len=1460) 
SSH server: Encrypted packet (len=232) 
SSH server: Encrypted packet (]en=1460) 
ssH server: Encrypted packet (len=1460) 
SSH server: Encrypted packet (len=1460) 
SSH server: Encrypted packet (len=1460) 
ssH server: Encrypted packet (len=1460) 
图 4 


那么 这 0.2 秒 之 间 究 竟 发 生 了 什么 呢 ? 我 把 过 滤 条 件 去 掉 后 得 到 了 








yz 4 





二 于 ， 


直到 0.2 秒 之 


后 AIX 的 Ack (534 写 包 ) 到 达 了 才 发 出 535 写 。Windows 停 下 来 的 原因 
是 什么 呢 ?” 它 在 这 两 个 包 里 总 共 才 发 了 700 多 字 节 (96+656) 的 数据 ， 





肯定 不 会 是 因为 TCP 窗 口 受 约束 所 致 。 


Filter: 


No. 
530 
531 
532 
533 
534 
535 
536 
537 





| 


ime 

411837000 
411838000 
411851000 
412387000 
606544000 
606583000 
606780000 
606856000 


局 口 口 口 口 口 口 口 


Source 
AIX 
AIX 
Windows 
Windows 
AIX 
Windows 
AIX 
AIX 


Destination 
Windows 
Windows 
AIX 
AIX 
Windows 
AIX 
Windows 
Windows 


[>| Expression.. Clear Apply Save 


Protocol Info 


SSH 
SSH 
TCP 
SSH 
TCP 
SSH 
SSH 
SSH 


server : Encrypted packet (len=1460) 

server : Encrypted packet (len=756) 

59140-~22 [ACK] seq=2641 Ack=631713 Win=64240 Len=0 
Client: Encrypted packet (len=96) 

22-59140 [ACK] Seq=631713 Ack=2737 Win=65535 Len=0 
Client: Encrypted packet (len=656) 

server: Encrypted packet (len=1460) 

server: Encrypted packet (len=1460) 


图 5 


如 果 你 研究 过 TCP 协 议 ， 可 能 已 经 想到 了 轴 策 窗口 综合 症 〈Silly 
window syndrome) 和 纳 格 〈Nagle) 算法。 在 某 些 情况 下 ， 应 用 层 传递 
给 TCP 层 的 数据 量 很 小 ， 比 如 在 SSH 客 户 端 以 一 般 速度 打字 时 ， 几 乎 是 
逐个 字 节 传 递 到 TCP 层 的 。 传 输 这 么 少 的 数据 量 却 要 耗费 20 字 节 卫 头 
+20 字 节 TCP 头 ， 是 非常 当 费 的 ， 这 种 情况 称 为 发 送 方 的 思 笨 窗口 综合 





证 ， 也 叫 “ 小 包 问 题 ”(small packet problem) 。 为 了 提高 传输 效率 ， 纳 
格 提出 了 一 个 算法 ， 用 程序 员 喜 闻 乐 见 的 方式 表达 就 是 这 样 的 : 
站 有 新 数据 要 发 送 
if 数 据 量 超过 MSS〈 即 一 个 TCP 包 所 能 携带 的 最 大 数据 量 ) 
立即 发 送 
else 
这 之 前 发 出 去 的 数据 尚未 确认 
把 新 数据 缓存 起 来 ， 凌 够 MSS 或 等 确认 到 达 再 发 送 
else 
立即 发 送 
end if 
end if 

end if 

图 5 所 示 的 状况 恰好 束 是 小 包 问 题 。Windows 发 了 533 号 包 之 后 ， 本 
应 该 立即 发 送 535 的 ， 但 是 由 于 535 携 带 的 数据 量 小 于 MSS， 是 个 小 包 ， 
根据 Nagle 算 法 只 好 等 到 533 被 确认 〈 即 收 到 534) 才能 接着 发 。 这 一 等 
就 是 0.2 秒 ， 所 以 性 能 受到 了 大 幅度 影响 。 那 为 什么 AIX 要 等 那么 久 才 确 
认 呢 ? 因为 它 启用 延迟 确认 了 ， 有 只 体 可 参考 本 书 的 《一 篇 天 于 VMware 
的 叉 章 》。 

Nagle 和 延迟 确认 本 里 都 没有 问题 ， 但 一 起 用 束 会 影响 性 能 。 解 决 
方法 很 简单 ， 要 么 在 Windows 上 关闭 Nagle 算 法 ， 要 么 在 AIX 上 关闭 延迟 
确认 。 这 位 客户 最 终 选 择 了 前 者 ， 性 能 立即 提升 了 20 倍 。 

如 果 你 足够 细心 ， 也 许 已 经 意识 到 网 3 有 问题 一 一 既然 传输 过 程 中 
会 频 汝 地 停顿 0.2 秒 ， 为 什么 图 3 显示 数据 传输 很 均匀 有 呢 ? 这 是 因为 抓 包 
时 间 太 长 了 ， 有 60 秒 ， 所 以 0.2 秒 的 停顿 在 图 上 看 不 出 来 。 假 如 只 截取 
其 中 的 一 秒 钟 来 分 析 ， 再 点 击 Statistics ,TCP StreamGraph , TCP 
Sequence Graph (Stevens) 采 单 ， 你 就 能 看 到 图 6 的 结果 ，0.2 秒 的 停顿 

















就 很 明显 了 。 


Sequence 
number[B] Time/Sequence Graph (Stevens) 


1000000 一 


900000 一 





0.05 010 0.15 0.20 0.25 0.30 0.35 0.40 0.45 0.50 0.55 0.60 0.65 0.70 0.75 0.80 





Time[s] 


图 6 

按理 说 ， 世 界 上 到 处 都 有 局 用 了 Nagle 和 延迟 确认 的 设备 在 通信 ， 
为 什么 很 少 有 人 说 起 呢 ? 我 猜测 大 多 数 受 害 者 并 没有 发 现 这 个 原因 ， 以 
为 是 市 宽 不 足 所 致 ， 所 以 就 一 直 忍 着 。 我 要 不 是 用 了 Wireshark， 也 是 发 
现 不 了 的 。 根 据 我 后 来 的 搜索 ， 只 有 斯 坦 福 大 学 的 博士 Stuart 系 统 地 阐 
述 过 一 个 现实 中 的 问题 ， 文 章 在 他 的 个 人 博客 上 
http:/www.stuartcheshire.org/papers/nagledelayedack/。 我 读 完 这 篇 文章 的 
感觉 就 像 遇 到 了 知音 ， 很 想 把 这 哥们 约 出 来 喝 一 杯 : 

“这 么 隐蔽 的 问题 你 是 怎么 发 现 的 ? 太 历 害 了 ! ” 

“和 满 兄 一 样 看 包 啦 ， 分 分 钟 的 事 ! 

“ 论 天 下 英雄 ， 唯 司徒 君 与 满 耳 。” 
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一 位 做 销售 的 朋友 最 近 非 常 郁 间 ， 因 为 即将 到 手 的 单子 被 竞争 对 手 
抢 走 了 。 他 在 饭局 上 诉 苗 的 时 候 ， 技 术 细 厄 引 起 了 我 的 极 大 兴趣 。 人 和 仔细 
询问 之 后 ， 我 把 症状 归纳 如 下 : 他 的 客户 是 一 家 超大 机 构 ， 内 部 组 织 非 
常 庞杂 ， 所 以 从 信息 化 的 角度 看 ， 有 些 用 户 (user) 属于 数 十 个 用 户 组 
Cgroup) 。 当 这 家 机 构 试 用 我 朋友 家 的 NFS 服 务 句 时 ， 发 现 了 一 个 诡异 
的 现象 ， 束 是 有 些 文件 明明 允许 某 个 用 户 组 访问 的 ， 但 是 属于 该 组 的 用 
户 却 访问 不 了 。 为 了 更 清楚 地 分 析 这 个 现象 ， 我 在 实验 室 搭 建 了 一 个 同 
样 的 环境 来 重 现 问题 。 

1. 在 Linux 客 户 病 创建 了 一 个 测试 账号 叫 linpeiman， 并 将 其 加 入 到 
20 个 用 户 组 中 ， 如 图 1 所 示 。 

呈 linpeiman@shifml:~/grouptest 


[linpeimanlshifml grouptest]$ groups 

groupl group2 group3 group4 groups groupé group7 group8 group9s 
groupli0 groupll groupl2 groupl3 groupl4 group1is groupli6 group 
17 groupli8 groupil3 group20 国 
[Linpeimaneshifm1 grouptest]$ 








[zeootQ@shitfml ~]# mount 10.32.106.45:/grouptest /home/linpeiman/grouptest 2 
[root@shifmi ~]# cd /home/linpeiman/grouptest/ 
OuUptest]# 








3. 用 root 账 号 在 共享 目录 中 创建 了 20 个 空 的 测试 文件 ， 然 后 把 它们 
逐个 分 配给 第 一 步 提 到 的 那 20 个 用 户 组 ， 并 将 权限 都 设 为 070〈 表 示 用 
户 组 拥有 所 有 访问 权限 ) ， 见 图 3。 理 论 上 账号 linpeiman 属 于 这 20 个 用 

















户 组 ， 所 以 应 该 对 这 20 个 文件 都 有 访问 权限 。 


[了 npPeimaneshiEmnl grouptest]$ ls -lhtr 
total 8.0K 

GE 13 21: 
Get 13 2Z1: 
OEE LB 21s 
OcE 13 2Z1: 
SE 1 1 
Oct 13 21: 
Oct 13 21: 
Oct 13 21: 
Oct 13 2Z1: 
Wet .13 
Oct 13 21: 
Oer T1323 21: 
Qer 1 1 
OE 13 过: 
Oct 13 21: 
Uet :13 2Z1: 
es 3 1s 


root groupl 

IOot group2 

Ioot group3 

root group4 

root groups 

root groups 

root group7 

root groups 

Ioot groupgd 

root groupli0 
root groupll 
root groupl2 
root groupl3 
root groupli4 
TOot grouplils 
root groupi6 
IOot groupl7? 
root groupl8 st 二 1 : 
一 一 一 一 卫 W 避 一 一 一 root groupigd Oct 13 21: 
ss root group20 5 Oct 13 21:; 
Ni[linpeiman@shifml grouptest]s 


Hs GG RY 1 


Cn 


-~-] [起 


LDO 


[he 


————IWEX-— 一 一 
-———IWX— 一 一 
—— 一 一 WI 一 一 一 


[Bm 


下 
= 


1 


Po 
Ka 人 


上 





4. 用 账号 linpeiman 逐 一 打开 〈cat) 这 些 文件 ， 发 现 前 16 个 没有 报 
错 ， 但 是 后 面 4 个 都 遭遇 了 Permission ”denied 错 误 ， 如 图 4 所 示 。 这 个 症 
状 束 好 像 linpeiman 不 属于 后 4 个 用 户 组 似 的 。 


| 一 人 
别 iinpeiman@shifml:~/grou 


[linpeiman@shifmi grouptest]$ ls -thr 





[linpeiman@shifmi grouptest]$ for EACH in ‘seq 1 20*; do cat S$EACH; done 


: Permission denied 

: Permission denied 

: 19: Permission denied 

: 20: Permission denied 
[linpeiman@shifmi Grouptest]S 








图 4 
我 觉得 这 个 实验 结果 完全 不 科学 。 分 明 是 一 模 一 样 的 配置 ， 为 什么 


就 有 些 文 件 不 可 以 访问 昵 ? 重复 了 几 次 实验 都 是 一 样 结果 ， 我 只 好 答 试 
一 些 其 他 的 方式 来 排查 。 

我 先 在 一 个 本 地 目录 中 创建 了 20 个 文件 ， 并 把 权限 设 成 跟 共享 目录 
上 的 一 样 ， 结 果 发 现 每 一 个 文件 部 可 以 顺利 打开 ， 见 图 5。 





克 linpeiman@shifml:~/local -= [9 
[linpeiman@shifm1 local]$ 1s -lhtr 





Oct 
Oct 
Oct 
Oct 
Oc 
Oct 
Oct 
Oct 
Oct 
Oct 


1 root groupi1 0 
1 root group2 0 
1 root group3 0 
1 root group4 0 
1 root group5s 0 
1 root Group6 0 
1 root group7 0 
1 root group8 0 
----rwx--- 1 root group9 0 
NN----rwx--- 1 root groupi0 0 
1 root groupii 0 
1 root groupi2 0 
1 root groupi3 0 
1 root groupi4 0 
1 root Gzoup15 0 
1 root groupi6 0 
1 root groupi7 0 
1 root groupi8 0 
1 root groupi9 0 
1 root group20 0 
Ni[linpeiman@shifm1 local]$ 工 








Ni[linpeiman@shifmi1 locall]$s 





既然 本 地 文件 是 好 的 ， 就 说 明 问 题 很 可 能 出 在 服务 器 上 。 而 且 根 据 
那 位 销售 朋友 的 说 法 ， 在 他 们 竞争 对 手 的 NFS 服 务 器 上 确实 不 存在 这 个 
问题 ， 不 知道 是 怎么 做 到 的 。 到 了 这 时 候 肯 定 要 “出 大 招 > 了 ， 我 在 访问 
这 些 文件 时 抓 了 个 网 络 包 下 来 分 析 。 

1. 既然 报错 是 Permission denied， 我 就 用 了 Ctrl+F 搜 索 字 符 
串 “denied”， 见 图 6。 





TI 
Find 
By: 人 Display filter 三 ) Hex value @ String 


Search In String 名 ptions 一 TDIrection 


@! Packet list Case sensitive © Up 
©) Packet details | | Character width: 昼 ! Down 


© Pocketbyees |||Narowarwide  @ 








2. 这 一 搜 果 然 找 到 了 服务 器 啊 应 的 375 号 包 ( 见 图 7〉， ， 定 位 到 了 
出 问题 的 时 间 点 。 不 过 真正 有 价值 的 却 是 它 的 上 一 个 包 ， 即 来 自 客户 端 
的 374 号 包 。 从 图 7 底部 可 见 RPC (Remote Procedure Call) 层 只 把 16 个 
Group ID 传 给 服务 器 ， 而 不 是 20 个 。 


No, _ Time Source Destination Protocol Info 
374 4.005940 Client server NFS V3 ACCESS Call (Reply In 375), FH: Oxc27dde52, [Check: RD MD XxT XE] 
375 4.006402 Server Client NFs V3 ACCESS Reply (Call In 3 [Eeeess cenied:] RD MD XT XxE] 


“| 

















eerns Type:call xID:0x60c1lc2ca 
田 EnaonenE eae Last fragment, 172 bytes 
XID: Ox60clc2ca (1623311050) 
Message Type: Call (0) 
RPC Version: 2 
Program: NFS (100003) 
Program Version: 3 
Procedure: ACCESS (4) 
[The reply to this reqguest is in frame 375 
日 Credentials 
Flavor: AUTH_UNIX (1) 
Length: 92 
stamp: Ox0038980f 
四 Machine Name: shifml 
UID: 505 
GID: 804 
由 Auxiliary GIDs (16)|[804, 805, 806, 807, 808, 809, 810, 811, 812, 813, 814, 815, 816, 817, 818, 819] 


图 7 
3. 这 些 ID 对 应 着 哪些 用 户 组 呢 ? 我 们 来 看 看 Linux 客 户 端 








的 /etc/group 文 件 ( 见 图 8)〉 ， 果 然 是 前 16 人 个， 后面 的 4 个 不 知道 为 什么 被 
遗漏 了 。 人 至 此 真相 大 白 ， 原 来 问题 根源 还 是 在 客户 端的 RPC 层 上 ， 不 知 
道 它 为 什么 遗漏 了 后 4 个 用 户 组 ， 服 务 器 是 被 冤枉 的 。 而 本 地 访问 之 所 
以 没有 出 问题 ， 是 因为 不 需要 调用 RPC 层 发 送 用 户 组 。 


:inpeiman, root 
:Hinpeiman, root 
:inpeiman, root 
:Hnpeiman, root 
:linpeiman, root 
:inpeiman, root 
:Minpeiman, root 
:Hinpeiman, root 











:Dinpeinman, root 
:Dinpeiman, root 
:inpeiman, root 
:和 inpeiman, root 
:Dinpeimany,root 
:Dinpeiman, root 
:inpeiman, root 
:linpeiman, root 
:linpeiman,root 
:linpeiman, root 
:linpeiman, root 
[linpeiman&shifmi1 grouptest]s 





图 8 
4. 我 查 了 了 RPC 协议 所 对 应 的 RFC 5531， 果 然 找 到 如 下 关 


于 “gids<16>” 的 定义 。 
structauthsys_parms { 
unsignedint stamp; 
stringmachinename<255>; 
unsignedintuid; 
unsignedintgid; 
unsignedintgids<16>; 
}; 
看 来 最 多 传 16 个 用 户 组 是 RFC 限 制 的 。 于 是 问题 来 了 ， 那 竞争 对 手 





是 怎样 避免 这 个 限制 的 呢 ? 一 番 调 查 之 后 ， 我 才 发 现 业 内 普遍 采用 了 一 
个 烦 为 “机智 ? 的 办 法 ， 即 把 客户 问 的 /etc/passwd 和 /etc/group 文 件 复制 到 
服务 器 上 ， 需 要 用 到 用 户 组 的 时 候 就 目 己 在 服务 右上 人 查询， 完全 忽略 客 
尸 端 通过 RPC 层 传 过 来 的 信息 。 其 实 这 样 做 会 有 后 遗 症 ， 比 如 以 后 在 客 
尸 端 修改 了 用 户 组 ， 但 是 忘记 同步 到 服务 右上 ， 就 会 出 现 访 问 问题 。 

对 我 这 位 做 销售 的 朋友 来 说 ， 虽 然 丢 了 单子 ， 但 是 通过 Wireshark 发 
现 了 根源 ， 能 亡羊补牢 也 是 好 的 。 说 不 定 下 一 个 单子 就 能 扳 回 来 呢 ? 








有 读者 来 信 问 ,，“ 林 工 ， 被 损坏 的 帧 在 Wireshark 中 是 长 什么 样子 
的 ? ”我 一 时 竟 不 知 如 何 回答 ， 因 为 虽然 阅 包 无 数 ， 但 从 来 没有 留意 过 
里 面 有 受 损 的 ， 更 不 知道 它们 长 成 什么 样子 。 后 来 仔细 一 想 ， 才 意识 到 
受 损 的 帧 本 来 就 不 会 显示 在 Wireshark 上 。 为 什么 呢 ? 这 涉及 数据 链 路 层 
的 错误 检测 机 制 FCS (Frame Check Sequence) : 每 个 帧 在 发 送 前 都 会 
被 发 送 方 校 验 一 次 ， 然 后 生成 4 个 字 节 的 FCS 存 在 帧 尾 。 接 收 方 拿 到 帧 
之 后 ， 又 会 用 相同 的 算法 再 做 一 次 校 验 并 生成 FCS。 假 如 这 次 生成 的 
FCS 和 帧 尾 携带 的 不 一 致 ， 束 说 明 该 帧 已 被 损坏 ， 应 该 丢弃 了 。 图 1 表 
示 了 一 个 以 太 网 帧 的 部 分 组 成 ， 由 于 校 验 是 由 网 卡 完成 的 ， 所 以 在 主机 
上 抓 包 一 般 看 不 到 FCS 区 域 ， 只 能 看 到 灰色 的 4 个 区 域 。 受 损 的 帧 则 所 
有 区 域 都 看 不 到 ， 因 为 整个 被 网 卡 丢 弃 了 。 


em] ， | 
图 1 

既然 如 此 ， 我 们 怎样 才能 判断 有 帧 损坏 呢 ? 有 的 时 候 抓 包 分 析 即 
可 ， 比 如 我 抓 包 发 现实 验 室 里 的 一 台 机 器 会 随机 丢 包 ， 即 便 在 没什么 流 
量 的 时 候 都 会 丢 。 因 此 我 判断 丢 包 不 是 拥塞 导致 的 ， 而 是 便 件 问题 导致 
了 帧 损坏 ， 后 来 换 了 根 光纤 线 果然 就 好 了 。 如 果 不 想 抓 包 ， 可 以 在 交换 
机 接口 上 检查 ”FCS 的 错误 统计 ， 比 如 下 面 的 show int 输 出 。Linux 上 的 
netstat-i 命 令 输出 综合 了 多 种 错误 ， 其 中 也 包括 FCS。 

Errors(Since boot or last clear) : 

FCS Rx : 142 Drops Rx : 0 

















Alignment Rx : 0 Collisions Tx : 0 


Runts Rx : 0 Late CollnTx : 0 
Giants Rx : 0 Excessive Colln: 0 
Total Rx Errors : 154 Deferred TIx :0 


以 上 这 套 理论 我 一 直 深 信 不 疑 ， 没 想到 上 周 偶然 抓 到 的 一 个 包 却 差 
点 颠覆 信仰 。 请 仔细 看 图 2 中 部 的 大 方 框 ， 我 竟然 在 一 台 普 通 主 机 上 抓 
到 了 一 个 帧 检验 序列 〈FCS) 错误 。 既 然 FCS 有 错 ， 表 示 帧 已 经 损坏 
了 ， 为 什么 没 被 网 卡 丢 弃 呢 ? 还 有 一 点 很 奇怪 的 ， 就 是 在 那些 没有 损坏 
的 帧 里 并 没有 看 到 FCS 信 息 《〈 和 截屏 就 不 贴 出 来 了 ) 。 既 然 要 显示 就 全 部 
显示 ， 为 什么 只 显示 出 错 的 FCS 呢 ? 


No. Time Source Destination Protocol Info 
381 1.680533 Client server UDP Source port: 59812 Destination port: 60752 [ 
4 | m 


由 Frame 381: 74 bytes on wire (592 bits), 174 bytes captured (592 bits 
Ethernet II, Src: 2d:74 




















pe: IP (Ox0800 


Trailer: 0100000042010000 
日 


日 [Expert Info (Error/Checksum): Bad checksum] 
[Bad checksum] 
[Severity level: Error] 
[Group: Checksum] 
由 Internet Protocol Version 4, src: Dst: 
日 User Datagram Protocol, src Port: 59812 (59812), Dst Port: 60752 (60752) 
source Port: 59812 (59812) 
Destination Port: 60752 (60752) 








图 2 

这 个 现象 已 经 诡异 到 不 能 用 现成 的 理论 来 解 秋 了， 难道 是 Wireshark 
的 误 报 吗 ? 我 仔细 观察 了 图 2 方 框 内 的 几 个 值 ， 发 现 还 真 的 是 : 在 UDP 
层 看 到 的 长 度 为 28 字 节 ， 算 上 IP 头 就 是 28+20=48 字 节 ， 再 算 上 帧 头 就 是 
48+14=62 字 节 。 怎 么 可 能 抓 到 74 字 市 呢 ? 多 出 来 的 这 12 字 节 无 法 解释 来 
源 。 我 只 能 猜测 这 人 台 主 机 出 了 问题 ， 把 其 他 帧 里 的 12 字 节 算 到 这 个 帧 里 
了 。 因 此 Wireshark 才 会 在 帧 尾 看 到 一 些 多 余 的 字 节 ， 束 错误 地 当 作 FCS 

















显示 出 来 了 。 假 如 这 个 猜测 是 对 的 ， 那 应 该 还 能 看 到 一 些 帧 是 有 缺失 字 
节 的 。 

没 想到 真 的 有 ， 请 看 图 3 的 351 号 包 。“UDP Length: 40” 表 明 UDP 层 
应 该 携带 40-8 (UDP 头 ) =32 字 节 才 对 ， 但 图 3 底部 的 UDP 层 却 只 携带 了 
20 字 节 的 数据 ， 说 明 有 12 个 字 节 莫名 其 妙 地 丢失 了 。 我 没有 证 据 表明 这 
12 个 字 节 一 定 就 是 图 2 多 出 来 的 那些 ， 但 很 可 能 就 是 。 由 于 这 些 字 节 
的 “漂移 "， 导 致 这 两 个 包 也 是 异常 的 ， 所 以 是 个 大 问题 。 后 来 客户 更 换 
了 IO 模块 ， 问 题 就 消失 了 。 


No, _ Time Source Destination Protocol Info 
351 1.680030 Client server UDP source port: 59812 Destination port: 60752 


和 mm 


田 Frame 351: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) 





























日 Ethernet II, Src: 2d:74 Dst: 4b:5c 
Type: IP (Ox0800) 
加 Internet Protocol Version 4, src: Client Dst: Server 





日 





Source Port: 59812 (59812) 
Destination Port: 60752 (60752 





日 
由 [Expert Info (Error/Malformed): Bad length value 40 > IP payload length] 
由 Checksum: Ox99d2 [unchecked, not all data available] 
[stream index: 2] 


PlData (20 bytes)) 








图 3 

Wireshark 就 是 这 么 神奇 。 虽 然 它 也 有 犯错 的 时 候 ， 但 是 由 于 包 里 方 
方面 面 的 信息 都 能 呈现 出 来 ， 所 以 我 们 可 以 进行 各 种 推理 ， 从 而 判断 出 
真正 的 问题 所 在 。 每 一 次 推理 都 是 对 网 络 基 础 知识 的 复习 过 程 ， 非 常 有 
价值 。 





上 个 月 收 到 了 一 封 读者 来 信 ， 说 我 上 本 书 中 的 一 个 截图 似乎 有 些 问 


题 ， 与 TCP 协 议 不 相符 。 理 论 上 TCP 断 开 连 接 时 的 四 次 挥手 应 该 是 图 1 这 
样 的 《假设 是 服务 器 先 要 求 断 开 ) 。 


TCP 四 次 挥手 





FIN Seq=X, Ack=Y (我 想 断 连接 ) 


Seq=Y, Ack=X+1 《知道 了 ， 肠 开 吧 ) 


FIN Seq=Y, Ack=X+1 (我 也 想 断 连接 ) 





Seq=X+1, Ack=Y+1 〈 知 道 了 ， 上 断 开 吧 ) 


服务 器 客户 端 


现实 抓 到 的 大 多 数 网 络 包 中 ，X 和 Y 的 值 也 符合 这 个 公式 。 如 图 2 所 











示 ， 你 可 以 把 这 些 数字 套 进 图 1 的 X 和 Y 计 算 一 下 ， 看 看 是 否 符合 规律 。 
0， Time Source Destination Protocol Info 

28 12.534915 Client server FTP 

29 12.536071 





Request: QUIT 

server Client FTP Response: 221 Goodbye. 

server Client TCP 21-~53431 [FIN, ACK] Seq=268 Ack=83 Win=139264 Len=0 
Client server TCP 53431~21 [ACK] Seq=83 Ack=269 Win=7925 Len=0 


30 12.536073 
31 12.536198 


33 12.539666 Server 





Client TCP 


21-53431 [ACK] Seq=269 Ack=84 Win=139264 Len=0 





图 2 
可 是 这 位 读者 发 现 上 本 书 中 却 有 图 3 这 样 的 一 张 图 。 仔 细 看 42 号 包 
的 Ack=442， 按 照 上 面 的 理论 它 本 应 该 是 Ack=442+1=443 的 ， 难 道 是 客 





LI » 
户 端 瑟 记 做 X+1 了 ? 
No, Time Source Destination Protocol Info 
39 10.378327 Client Server FTP Request: QUIT 


40 10.378468 Server Client FTP Response: 221 Goodbye. 
41 10.378474 Server Client TCP 21-~36115 [FIN, ACK] Seq=442 Ack=107 Win=139264 Len= 
42 10.378491 Client Server TCP 36115-21 [ACK] Seq=107 Ack=442 Win=5856 Len=0 TSvVval: 











Client TCP 21-36115 [ACK] Seq=443 Ack=108 Win=139264 Len=0 TSV, 
图 3 

这 封 来 信 让 我 十 分 震惊 ， 因 为 该 图 本 身 演示 的 是 FTP 协 议 ， 没 想到 
这 位 读者 连 传输 层 的 细节 都 研究 了 ， 如 此 精细 的 读 法 让 我 觉得 写 书 压力 
好 大 ;而 且 这 个 发 现 十 分 中 肯 ， 我 也 觉得 是 客户 端 筷 记 作 X+1 了 ， 出 版 
之 前 竟然 没 注意 到 这 个 bug。 

书 中 出 了 差错 还 不 算是 最 糟糕 的 ， 更 大 的 问题 是 在 很 多 机 器 上 抓 包 
都 发 现 了 这 个 现象 。 你 可 不 要 小 瞧 它 ， 四 次 挥手 时 用 错 Ack 值 会 有 什么 
后 果 呢 ? 它 可 能 导致 TCP 连 接 断 开 失 败 ， 留 下 一 个 本 不 应 该 存在 的 连 
接 ， 久 而 久之 就 会 导致 新 连接 建立 失败 。 那 就 属于 大 bug 了 ， 得 赶紧 上 
报 才 行 。 奇 怪 的 是 我 做 了 几 个 实验 都 发 现 能 成 功 断 开 ， 难 道 是 我 对 协议 
的 理解 有 偏差 吗 ? 在 接 下 来 的 几 天 里 ， 我 仔细 地 查阅 了 TCP 的 多 个 RFC 
版 本 ， 比 如 RFC 793、1323、5681 等 ， 企 图 找 出 一 个 相关 的 解释 ， 但 都 
没有 找到 。 

几 天 后 我 跟 Patrick〈( 是 的 ， 就 是 我 上 本 书 中 介绍 的 那 位 奇人 〉 聊 天 
时 提 到 了 这 件 事情 ， 老 人 家 很 快 就 回答 , “你 考虑 过 延迟 确认 对 四 次 挥 
手 的 影响 吗 ? 这 个 包 一 点 问题 都 没有 哦 。”* 延 迟 确认 我 当然 知道 了 ， 它 
省 挤 了 四 次 挥手 中 的 第 二 个 包 ， 变 成 下 面 图 4 的 样子 。 


44 10.378867 Server 























TCP 四 次 挥手 


FIN Seq=X, Ack=Y (我 想 断 连接 ) 


FIN Seq=Y Ack=X+1 (知道 了 ， 
断 开 吧 。 我 也 想 断 连接 ) 


Seq=X+1, Ack=Y+1 《知道 了 ， 断 开 吧 ) 





图 4 
我 在 生产 环境 中 也 抓 到 过 这 个 现象 。 见 图 5 的 33、34、35 写 包 ， 就 
符合 上 述 的 模型 。 可 是 这 跟 图 3 的 现象 还 是 不 一 样 啊 。 
能 es 和 i Data: 40 bytes 


32 9.308361 Client Server TCP 33001-61657 [ACK] Seq=1 Ack=41 Win=5856 Len=0 TSval=9401060 
33 9.308363 server Client TCP 61657~33001 [FIN, ACK] Seq=41 Ack=1 Win=65536 Len=0 TSval=4 








35 9.308630 Sserver Client TCP 61657~33001 [ACK] Seq=42 Ack=2 Win=65536 Len=0 TSval=421211 








图 5 
Patrick 进 一 步 点 拨 ， 如 果 拿 挥 图 3 中 的 42 号 包 ， 不 就 跟 图 5 的 延 人 运 确 
认 场 景 一 模 一 样 吗 ?也 是 用 三 个 包 完 成 了 挥手 。 那 42 号 包 又 是 怎么 多 出 
来 的 呢 ? 我 很 快 也 想 通 了 : 这 些 包 是 在 服务 器 上 抓 的， 网 络 上 又 存在 延 
迟 ， 所 以 跟 客 户 端 上 看 到 的 顺序 可 能 不 一 样 。 我 的 眼睛 看 着 服务 器 上 抓 
的 包 ， 脑 子 却 从 客户 端的 角度 思考 ， 所 以 才 会 被 混 消 。 那 在 客户 端 上 看 
到 的 包 应 该 是 怎样 的 呢 ? 发 挥 一 下 想象 力 ， 真 相应 该 如 图 6 所 示 ， 网 络 














延 时 导致 41 号 包 和 42 号 包 在 传输 时 发 生 了 时 间 上 的 "交叉 ?。 从 客户 端的 
角度 看 ，41 号 包 和 42 号 包 的 顺序 应 该 颠倒 一 下 才 对 。 也 就 是 说 42 号 包 根 
本 就 没有 参与 四 次 挥手 过 程 ， 它 只 是 用 来 确认 收 到 40 号 包 而 已 ， 但 由 于 
网 络 延 迟 使 它 到 达 服 务 器 时 排 在 了 41 号 包 后 面 ， 所 以 看 上 去 就 像 挥 手 过 
程 的 一 部 分 。 更 巧 的 是 延迟 确认 把 四 次 挥手 减少 成 3 个 包 ， 所 以 就 更 有 
迷惑 性 了 。 








TCP 四 次 挥手 





服务 伏 客户 站 


图 6 
多 谢 这 位 眼 尖 的 读者 。 虽 然 没有 发 现 大 bug， 但 这 个 发 现 对 我 们 做 
网 络 分 析 非 常 有 借鉴 意义 。 在 本 书后 面 的 一 些 文章 中 ， 还 会 讲 到 类 似 的 
情况 。 如 果 你 在 这 里 己 经 觉得 有 点 军 了 ， 建 议 再 细 细 阅读 一 裔 。 作 为 





Wireshark 见 练 工 ， 必 须 能 从 一 端 抓 到 的 网 络 包 中 推测 出 另 一 端的 概况 ， 
才能 分 析出 那些 最 复杂 的 问题 。 


NTLM 协 议 分 析 


有 位 读者 做 项 目 时 过 到 了 麻烦 ， 就 抓 了 个 网 络 包 来 找 我 分 析 。 我 粗 
略 一 看 ， 身 份 验证 协议 用 的 竟然 是 NTLM， 便 建议 他 改 用 Kerberos。 没 
想到 对 方 说 NTLM 目 前 在 中 国 还 是 用 得 很 多 的 ， 不 想 改 。 我 将 信 将 疑 ， 
咨询 了 几 位 在 一 线 做 实施 的 工程 师 才 确认 ， 据 说 连 某 大 银行 内 部 的 文件 
服务 器 都 完全 靠 NTLM 做 身份 验证 。 既 然 如 此 ， 我 就 来 写 一 篇 NTLM 的 
工作 原理 吧 ， 对 中 国 读 者 应 该 会 有 好 处 。 

NTLM 的 全 称 是 NT LAN Manager， 是 Windows NT 时 代 就 出 现 的 身 
份 验证 协议 。 大 多 数 人 都 用 到 过 NTLM， 却 没有 意识 到 它 的 存在 。 我 们 
可 以 做 个 简单 的 实验 来 演示 。 

1. 如 图 1 所 示 ， 我 在 电脑 上 输入 了 一 个 网 络 共 享 的 路 径 ， 再 按 一 下 








Em 


Type the name of a program, folder, document, or Internet 
resource, and Windows will open it for You， 


OQpen: “10.32.106.207\tearm_shard 


Ee 





图 1 
2. 图 2 的 对 话 框 跳出 来 了 ， 要 求 喘 份 验 证 ， 即 输入 用 户 名 和 密码。 


Windows Security 


Enter Network Password 
Enter your password to connect to: 10,.32.106,.207 





一 -一 一 | wn.com\administrator | 


| ] 


| 1 Domaim: wnx.com 
[|_| Remember my credentials 





BE Logon faillure: unknown user name or bad password, 


图 2 


3. 完成 了 图 2 这 一 步 ， 网 络 共 享 就 打开 了 ， 我 们 就 可 以 访问 里 面 的 
A 

在 此 过 程 中 ， 实 际 上 就 用 到 了 NTLM 来 验证 身份 。 我 们 来 看 看 在 
Wireshark 中 是 怎样 体现 的 。 

1. 客户 端 癌 服务 器 发 送 了 一 个 NTLM 协 商 请 求 ， 然 后 服务 器 立即 
回复 一 个 随机 字符 串 作 为 Challenge〈 见 图 3) 。 这 个 Challenge 有 什么 用 
呢 ? 我 们 后 面 会 详细 讲 到 。 注 意 服务 器 的 回复 虽然 是 “Error: 
STATUS_MORE_PROCESSING_REQUIRED”， 看 上 去 好 像 是 出 错 了 ， 
但 实际 上 这 个 所 谓 的 Error 是 正常 流程 的 一 部 分 。 











Piter ntimssp [| Expression.. Clear Apply Save 
No, Time Source Destination Protocol Info 
216 12.003906 Client Server SMB2 Session Setup Request, NTLMSSP_NEGOTIATE 


217 12.003906 Server Client SMB2 Session Setup Response, Error: STATUS MORE_PROCESSING_ REQUIRED, NTLMSSP_CHALLENGE 
« 中 


3 NTLM Secure Service Provider 
NTLMSSP identifier : NTLMSSP 
NTLM Message Type: NTLMSSP_CHALLENGE (Ox00000002) 
田 Target Name: VNX 


田 Negotiate Flags: Oxe0898211 
NTLM Server Challenge: 24228cl190bcd035g| 








图 3 
2. 客户 端 收 到 Challenge 之 后 ， 同 服务 器 回复 了 图 2 中 输入 的 那个 用 
户 名 VNX\Administrator， 以 及 两 个 Response 值 〈 见 图 4) 。 这 两 个 
Response 是 哪 来 的 呢 ? 它们 都 是 用 hash 过 的 用 户 密 码 对 Challenge 所 进行 
的 加 密 ， 两 种 不 同 的 加 密 方 式 产生 了 两 个 不 同 的 Response。 加 密 过 程 就 
不 细 说 了 ， 绝 大 多 数 读 者 并 不 需要 知道 (其 实 是 因为 作者 自己 也 了 解 不 
全 下 











Filter ntlmssp [=| Expression.. Clear Apply Save 
No, Time Source Destination Protocol Info 
216 12.003906 Client Sserver B2 


session setup Request, NTLMSSP_NEGOTIATE 
217 12.003906 Server Client SMB2 


Session setup Response, Error: STATUS_MORE_PROCESSING _ REQUIRED, NTLMSSP_CHALLENGE 
218 12.003906 Client Server SMB2 Session Setup Request, NTLMSSP_AUTH, User: 
* 上 


3 NTLM Secure Service Provider 
NTLMSSP identifier : NTLMSSP 
NTLM _ Message pe: NTLMSSP_AUTH (0x00000003 
和 ; a7790a618ed46070 f5 








3. 服务 器 收 到 了 之 后 ， 是 不 知道 该 怎样 验证 这 些 Response 的 真 假 
的 。 因 此 它 就 把 Challenge 和 两 个 Response 都 转发 给 域 控 (Domain 
Controller) ， 让 域 控 去 帮忙 验证 真 假 。 在 图 5 中 可 以 看 到 ， 转 发 给 域 控 
的 Challenge 和 Response 和 图 3、 图 4 里 的 是 一 样 的 。 





No. Time Source Destination Protocol Info 
267 12.011718 Server DC RPC_NETLOGON NetrLogonsamLogon request 
268 12.015625 DC Server RPC_NETLOGON NetrLogonsamLogon response 





4 | th 





田 IDENTITY_INFO: Administrator 
Challenge: 54228c190bcd0356 
日 LM Chal resp 
Length: 176 
size: 176 
日 Bytes Array 
Referent ID: 0x00747055 
Max Count: 176 
offset: 0 
Actual Count: 176 
日 LM Chal resp 
Length: 24 
Ssize: 24 
日 Bytes Array 
Referent ID: Ox00747055 
Max Count: 24 
offset: 0 
Actual Count: 24 
LM Chal resp: a//’90abl8ed46070ceaft 5d7111459ceb69bOd/Tb374b041cC2 


图 5 
4. 域 控 收 到 之 后 ， 也 用 hash 过 的 用 户 密 码 对 该 Challenge 进 行 加 
密 。 人 就 说 明 密 码 正确 ， 身 份 验证 
通过 。 在 响应 时 ， 域 控 还 会 把 该 用 户 所 属 的 群 组 信息 告知 服务 器 ， 见 图 


团 











6 底部 所 示 。 

No. Time Source Destination Protocol Info 
267 12.011718 Server DC RPC_NETLOGON NetrLogonsamLogon request 
268 12.015625 DC Server RPC_NETLOGON NetrLogonsamLogon response 
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GROUP_MEMBERSHIP_ARRAY 

Referent ID: Ox0002000c 
Max Count: 5 

由 GROUP_MEMBERSHIP : 

由 GROUP_MEMBERSHIP : 

GROUP_MEMBERSHIP : 

由 GROUP_MEMBERSHIP : 

由 GROUP_MEMBERSHIP : 





图 6 
5. 于 是 服务 器 就 可 以 告诉 客户 端 , “你 的 号 份 验证 通过 了 。?” 见 图 7 
的 289 写 包 。 如 果 失 败 的 话 ， 你 看 到 的 就 不 是 这 么 简单 的 “Session Setup 
Response” 了 ， 而 是 某 个 Error。 








No Time Source Destination 
216 12.003906 Client Server 
217 12.003906 Sserver Client 
218 12.003906 Client Sserver 
289 12.015625 Sserver Client 
yy AT 口 下 
这 个 过 程 总 结 





Protocol 
SMB2 
SMB2 
SMB2 
SMB2 


我 想 用 NTLM 做 身份 验证 


Info 

Session Setup Request, NTLMSSP_NEGOTIATE 

session Setup Response, Error: STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE 
Session Setup Request, NTLMSSP_AUTH, User: VNX\Administrator 

session Setup Response 


图 7 


下 来 就 如 图 8 所 示 ， 比 起 Kerberos 还 是 比较 简单 的 。 





那 你 报 上 名 号 ， 再 把 这 段 字符 串 加 密 给 我 看 。 


我 叫 XXX， 加 密 结 果 如 下 : 


你 的 身份 验证 通过 了 。 


大 哥 ， 你 帮 有 我 看 看 这 人 是 不 是 真 的 ? 


真 的 ， 我 还 找到 他 属于 下 列 群 组 : 


图 8 


明白 了 原理 ， 我 们 就 可 以 理解 NTLM 的 很 多 特征 了 。 

1. 由 于 从 包 里 能 看 到 Challenge 和 Response， 算 法 也 是 固定 的 ， 所 
以 密码 存在 被 破解 的 可 能 。 因 此 微软 并 不 推荐 NTLM， 从 官网 吏 可 以 看 
到 “Therefore，applications are generally advised not to use NTLM 〈 因 此， 
一 般 不 建议 应 用 程序 使 用 NTLM) ”。 

2. 客户 剖 每 访问 一 次 服务 器 ， 束 得 让 域 控 帮 忙 验证 一 次 映 份 ， 增 
加 了 域 控 的 负担 。 如 果 改 用 Kerberos 就 能 使 用 缓存 的 ticket， 减 少 访问 域 
控 的 次 数 。 

3. 有 些 场 合 也 能 体现 出 先进 性 ， 比 如 当 一 个 用 户 不 属于 某 群 组 ， 
所 以 访问 不 了 资源 时 。 人 解决 方式 是 在 域 控 上 为 该 用 户 账号 添加 群 组 ， 这 
时 如 果 用 Kerberos 融 得 重新 登录 来 获得 新 的 群 组 信息 ， 用 NTLM 则 不 


用 。 





当 我 们 遇 到 NTLM 问 题 的 时 候 ， 用 Wireshark 来 排 得 是 最 合适 不 过 


的 ， 客 户 端 、 服 务 右 和 域 控 的 问题 都 能 发 现 。 比 如 客户 端 有 时 会 在 图 4 
的 包 中 使 用 一 个 空 的 用 户 名 ， 或 者 其 它 出 人 意料 的 账号 来 验证 身份 ， 这 
种 现象 在 Wireshark 中 一 目 了 然 。 域 控 导 致 的 问题 可 能 我 们 自己 解决 不 
了 ， 需 要 联系 微软 技术 文 持 ， 但 是 在 此 之 前 用 Wireshark 定 位 会 快 很 多 。 
比如 不 和 久 前 我 遇 到 过 一 个 身份 验证 失败 的 案例 ， 在 Wireshark 中 看 到 的 域 
控 报 错 如 图 9 所 示 ， 我 们 据 此 就 能 把 问题 定位 到 域 控 上 。 微 软 的 工程 师 
也 是 根据 这 个 报错 修改 了 Group Policy 来 解决 的 。 这 种 问题 如 果 没 有 用 
到 Wireshark， 可 能 连 判 断 是 哪 一 方 导致 的 都 不 容易 。 


RPC_NETLOGON NetrLogonsamLogon regquest 
RPC_NETLOGON NetrLogonsamLogon response, STATUS_ACCESS_DENIED 
图 9 





Wireshark 上 的 提示 


最 近 有 不 少 同事 开始 学 习 Wireshark， 他 们 遇 到 的 第 一 个 困难 就 是 理 
解 不 了 主 界面 上 的 提示 信息 ， 于 是 跑 来 问 我 。 问 的 人 多 了 ， 我 也 总 结 成 
一 篇 文章 ， 希 望 对 大 家 有 所 帮助 。Wireshark 的 提示 可 是 其 最 有 价值 之 
处 ， 对 于 初学 者 来 说 ， 如 采 能 理解 这 些 提 示 所 隐 含 的 意义 ， 学 起 来 定 能 
事半功倍 。 

1. [Packet size limited during capturel] 

当 你 看 到 这 个 提示 ， 说 明 被 标记 的 那个 包 没 有 抓 全 。 以 图 1 的 4 号 包 
为 例 ， 它 全 长 有 171 字 节 ， 但 只 有 前 96 个 字 节 被 抓 到 了 ， 因 此 Wireshark 


























/人 日 一 = 

2 了 了 此 提示 o 

No, _ Time Source Destination Protocol Info 
1 0.000000 Client server TCP 48113-443 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PE 
2 0.001482 server Client TCP 443-48113 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1 
3 0.001501 Client server TCP 48113-.443 [ACK] Segq=1 Ack=1 Win=5856 Len=0 TSval=4157 
4 0.009432 Client server ssL Packet size limited during capture 
3 0.010923 _ Server Client _TCP 443-48113 [ACK| Seq=1 Ack=106 Win=5792 Len=0 TSval=43 

< MW 

由 Frame 4: |171 bytes on wire (1368 bits 96 bytes capturedl (768 bits) 





图 1 

这 种 情况 一 般 是 由 抓 包 方式 引起 的 。 在 有 些 操作 系统 中 ，tcpdump 
默认 只 抓 每 个 帧 的 前 96 个 字 节 ， 我 们 可 以 用 “-s” 参 数 来 指定 想 要 抓 到 的 
字 节 数 ， 比 如 下 面 这 条 命令 可 以 抓 到 1000 字 节 。 

[root@my_server/l#tcpdump -i eth0 -s 1000 -w/tmp/tcpdump.cap 

2. [LTCP Previous segment not captured | 

在 TCP 传 输 过 程 中 ， 同 一 台 主 机 发 出 的 数据 段 应 该 是 连续 的 ， 即 后 
一 个 包 的 Seq 号 等 于 前 一 个 包 的 Seq+Len 〈 三 次 握手 和 四 次 挥手 是 例 
外 ) 。 如 果 Wireshark 发 现 后 一 个 包 的 Seq 号 大 于 前 一 个 包 的 Seq+Len， 
就 知道 中 间 缺 失 了 一 段 数据 。 假 如 缺失 的 那 段 数据 在 整个 网 络 包 中 都 找 


不 到 《〈 即 排除 了 乱 序 ) ,就 会 提示 [TCP Previous segment not 
captured ] 。 比 如 在 图 2 这 个 例子 中 ，6 号 包 的 Seq 号 1449 大 于 5 号 包 的 
SeqtLen=1+0=1， 说 明 中 间 有 个 携 珊 1448 字 节 的 包 没 被 抓 到 ， 它 就 

是 “Seq=1，Len=1448”。 


No. Time Source Destination Protocol Info 





1 0.000000 Client server TCP 48113-443 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval= 

2 0.001482 server Client TCP 443-48113 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PEI 

3 0.001501 Client Server TCP 48113-443 [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSval=41576587 TSecr= 

4 0.009432 Client server SSL [Packet size limited during capture] 

5 0.010923 server Client TCP 443-48113 [ACK] [Sedq=T Ack=106 win=5792 [Cen=0] Tsval=439748224 Tse 

6 0.011691 Server Client SSL Continuation Data[Packet sizl 
| 


站 i 

3 Transmission Control Protocol, Src Port: 443 (443), Dst Port: 48113 (48113), |seq: 1449| Ack: 106, 
Source Port: 443 (443) 
Destination Port: 48113 (48113) 











图 2 

网 络 包 没 被 抓 到 还 分 两 种 情况 : 一 种 是 真 的 于 了 ; 男 一 种 是 实际 上 
没有 丢 ， 但 被 抓 包 工具 漏 掉 了 。 在 Wireshark 中 如 何 区 分 这 两 种 情况 呢 ? 
只 要 看 对 方 回 复 的 确认 (Ack) 束 行 了 。 如 有 果 该 确认 包含 了 没 抓 到 的 那 
个 包 ， 那 就 是 抓 包工 具 漏 掉 而 已 ， 人 否则 就 是 真 的 丢 了 。 

顺便 分 析 一 下 图 2 这 个 网 络 包 ， 它 是 HTTPS 传 输 异 常 时 在 客户 端 抓 
的 。 因 为 Len: 667” 的 小 包 ( 即 6 号 包 )〉 可 以 送 达 ， 但 “Len: 1448” 的 大 
包 却 于 了 ， 说 明 路 径 上 可 能 有 个 网 络 设备 的 MTU 比 较 小 ， 会 丢弃 大 
包 。 后 来 的 解雇 方式 证 实 了 这 个 猜测 ， 只 要 把 整个 网 络 路 径 的 MTU 保 
持 一 至， 问题 就 消失 了 。 

3. [TCPACKed unseen segment] 

当 Wireshark 发 现 被 Ack 的 那个 包 没 被 抓 到 ， 束 会 提示 [TCP ACKed 
unseen segment]。 这 可 能 是 最 常见 的 Wireshark 提 示 了 ， 幸 好 它 几 乎 是 永 
远 可 以 忽略 的 。 以 图 3 为 例 ，32 号 包 的 Seqt+Len=6889+1448=8337， 说 明 
服务 器 发 出 的 下 一 个 包 应 该 是 Seq=8337。 而 我 们 看 到 的 却 是 35 号 包 的 
Seq=11233， 这 意味 着 8337 一 11232 这 段 数 据 没 有 被 抓 到 。 这 上段 数据 本 应 
该 出 现在 34 号 之 前 ， 所 以 Wireshark 提 示 了 [TCPACKed unseen 


segment]。 























No, Time Source Destination Protocol Info 


32 1.256720 Server Client TCP [continuation to #26] 445-2199 [ACK] Ack=885 win=65535 [Cen=1448] Tsval=3787 

33 1.256729 Client Server TCP 2199-445 [ACK] seq=885 Ack=8337 Win=2920 Len=0 TSval=27476 TSecr=378779 

34 1.256961 Client Server TCP 2199-445 [ACK] Seq=885 Ack=11233 Win=2920 Len=0_TSval=27 

35 1.257191 server Client TcPp ContinuatTion to #26] TiCP previous segment not captured] 445-2199 [ACK] 
图 3 


不 难 想 象 ， 在 一 个 网 络 包 的 开头 会 经 常 看 到 这 个 提示 ， 因 为 只 抓 到 
了 后 面 的 Ack 但 没 抓 到 前 面 的 数据 包 。 

4. [TCP Out-of-Order] 

在 TCP 传 输 过 程 中 《〈 不 包括 三 次 握手 和 四 次 挥手 ) ， 同 一 台 主 机 发 
出 的 数据 包 应 该 是 连续 的 ， 即 后 一 个 包 的 Seq 号 等 于 前 一 个 包 的 
Seq+Len。 也 可 以 说 ， 后 一 个 包 的 Seq 会 大 于 或 等 于 前 一 个 包 的 Seq。 当 
Wireshark 发 现 后 一 个 包 的 Seq 号 小 于 前 一 个 包 的 Seq+Len 时 ， 束 会 认为 





是 乱 序 了 ， 因 此 提示 [TCP Out-of-Order]。 如 图 4 所 示 ，3362 号 包 的 
Seq=2685642 小 于 3360 号 包 的 Seq=2712622， 所 以 就 是 乱 序 。 
No, Time Source Destination Protocol Info 





3360 5.007813 Server Client TCP 49454-8888 [ACK] lsSeq=2712622| Ack=2761 Win=32768 
3361 5.007813 Client Sserver TCP 8888-49454 [ACK] Seq=2761 Ack=2639576 Win=2457 L 


3362 5.007813 Server Client TCP [TCP Out-Of-Order|| 49454-8888 [ACK] |segq=2685642 
3363 5.007813 Client Server TCP 8888-49454 [ACK| Seq=2761 Ack=2664291 Win=2457 L 


图 4 

小 跨度 的 乱 序 影响 不 大 ， 比 如 原本 顺序 为 1、2、3、4、5 号 包 被 打 
乱 成 2>、1、3、4、5 束 没事 。 但 跨度 大 的 乱 序 却 可 能 触发 快速 重 传 ， 比 
如 打 乱 成 2>、3、4、5、1 时 ， 就 会 触发 足够 多 的 Dup ACK， 从 而 导致 1 号 
包 的 重 传 。 

5. [TCP Dup ACK] 

当 乱 序 或 者 丢 包 发 生 时 ， 接 收 方 会 收 到 一 些 Seq 号 比 期 望 值 大 的 
包 。 它 每 收 到 一 个 这 种 包 就 会 Ack 一 次 期 望 的 Seq 值 ， 以 此 方式 来 提醒 发 
送 方 ， 于 是 就 产生 了 一 些 重复 的 Ack。Wireshark 会 在 这 种 重复 的 Ack 上 
标记 [TCP Dup ACK]。 

以 图 5 为 例 ， 服 务 嚣 收 到 的 7 号 包 为 “Seq=29303，Len=1460”， 所 以 
它 期 望 下 一 个 包 应 该 是 Seq+Len=29303+1460=30763， 没 想到 实际 收 到 
的 却 是 8 号 包 Seq=32223， 说 明 Seq=30763 那 个 包 可 能 丢失 了 。 因 此 服务 














器 立即 在 9 号 包 发 了 Ack=30763， 表 示 “ 我 要 的 是 Seq=30763”。 由 于 接 下 
来 服务 器 收 到 的 10 号 、12 号 、14 号 也 都 是 大 于 Seqd=30763 的 ， 因 此 和 它 每 
收 到 一 个 就 回复 一 次 Ack=30763， 从 图 中 可 见 Wireshark 在 这 些 回 复 上 都 
标记 了 [TCP Dup ACK]。 


No. ime Source Destination Protocol Info 

7 0.007813 Client server TcPp [continuation to #3] 55448-445 [ACK] [Se9=29303] Ack=245 win=868 [Cen=1460] 

8 0.007813 Client server TCP [Continuation to #3] [TCP Previous segment not captured] 55448-445 [ACK] [Se0=32223] 
9 0.007813 Server Client TCcPp 445-55448 [ACK] seq=245 [ck=30763]win=16384 Len=0 SLE=32223 SRE=33683 

10 0.007813 Client Server TCP [Continuation to #3] 55448-445 [ACK] Seq=33683 Ack=245 Win=868 Len=11680 

11 0.007813 Server Client Tcp [TCP Dup ACK 9#1] 445-55448 [ACK] seq=245 Eck=30763] win=16384 Len=0 SLE=32223 SRE=4 
12 0.007813 Client SerVver TCP [Continuation to #3] 55448-445 [ACK] Seq=45363 Ack=245 Win=868 Len=1460 

13 0.007813 Server Client TcP [TcP Dup ACK 9#2] 445-55448 [ACK] Seq=245 [ACK=30763] win=16384 Len=0 SLE=32223 SRE=4 








14 0.007813 Client server TCP [Continuation to #3] 55448-445 [ACK] Seq=46823 Ack=245 Win=868 Len=1460 
15 0.007813 Sserver Client TcP [TCP Dup ACK 9#3] 445-55448 [ACK] Seq=245 [REKE3075 习 win=16384 Len=0 SLE=32223 SRE=4 


6. [TCP Fast Retransmission | 

当 发 送 方 收 到 3 个 或 以 上 [TCP Dup ACK]， 就 意识 到 之 前 发 的 包 可 
能 于 了 ， 于 是 快速 重 传 它 (这 是 RFC 的 规定 ) 。 以 图 6 为 例 ， 客 户 端 收 
到 了 4 个 Ack=991851， 于 是 在 1177 号 包 重 传 了 Seq=991851。 


No. Time Source Destination Protocol Info 

1169 0.882813 Server Client TCP 49454-8888 [ACK] Seq=1098048 Ack=1105 Win=32768 Len=1448 1 
1170 0.882813 Sserver Client TCP 49454~8888 [ACK] Seq=1099496 Ack=1105 Win=32768 Len=1018 1 
1171 0.882813 Client Server TCP 8888-49454 [ACK] seq=1105 Win=2457 Len=0 TSval= 
1172 0.882813 Server Client TCP 49454~8888 [ACK] Seq=1100514 Ack=1105 Win=32768 Len=1448 1 
1173 0.882813 Server Client TCP 49454--8888 [ACK] Segq=1101962 Ack=1105 Win=32768 Len=1017 1 


1174 0.882813 Client Server TCP [TCP Dup ACK 1171#1]| 8888-49454 [ACK] Seq=1105 |IAck=991851 
[TCP Dup ACK 1171#2]| 8888-49454 [ACK] Seq=1105 
[TCP Dup ACK 1171#3]| 8888--49454 [ACK] Seq=1105 


1175 0.886719 Client server TCP ACK=991851 
1176 0.886719 Client Server TCP ACK=991851 

49454-8888 [ACK] [EEGE55185T Ack- 
图 6 





















1177 0.886719 server Client TCP 


7. [TCP Retransmission] 

如 果 一 个 包 真 的 于 了 ， 义 没有 后 续 包 可 以 在 接收 方 触 发 [Dup 
Ack]， 融 不 会 快速 重 传 。 这 种 情况 下 发 送 方 只 好 等 到 超时 了 再 重 传 ， 此 
类 重 传 包 就 会 被 Wireshark 标 上 [TCP Retransmission]。 以 图 7 为 例 ， 客 户 
问 发 了 原始 包 【〈 包 号 1053) 之 后 ， 一 直 等 不 到 相应 的 Ack， 于 是 只 能 在 
100 多 坚 秒 之 后 重 传 了 了 〈 包 号 1225) 。 


Filter tcp.seq == 1012852 | ~] Expression.. Clear Apply Save 





No. _ Time Source Destination Protocol Info 
1053 0.804688 Client server TCP 49454-8888 [ACK] 1jseq=1012852| Ack=1105 Win=32768 Len=! 
1225 0.937500 Client server TCP [TCP Retransmission] 49454-~8888 [ACK] ljseq=1012852| Acl 


图 7 


超时 重 传 是 一 个 非常 有 技术 含量 的 知识 点 ， 比 如 等 待 时 间 的 长 短 就 


大 有 学 问 ， 本 文 就 不 细 说 了 ， 上 毕竟 需要 懂 这 个 的 人 很 少 。 

8. [ICP zerowindow!] 

TCP 包 中 的 “win=” 代 表 接 收 窗 口 的 大 小 ， 即 表示 这 个 包 的 发 送 方 当 
前 还 有 多 少 缓存 区 可 以 接收 数据 。 当 Wireshark 在 一 个 包 中 发 
现 “win=0” 时 ， 就 会 给 它 打 上 “TCP ”zerowindow” 的 标志 ， 表 示 绥 存 区 已 
满 ， 不 能 再 接收 数据 了 。 比 如 图 8 就 是 服务 器 的 绥 存 区 已 满 ， 所 以 通知 
客户 端 不 要 再 发 数据 了 。 我 们 甚至 可 以 在 3258 一 3263 这 几 个 包 中 看 出 它 





0. Time Source Destination Protocol Info 













3258 3.140625 Server Client TCP 8888-62758 [ACK] Seq=7467 Ack=11928601 Win=15872 Len=0 TSval=226971 
3259 3.140625 Server Client TCP 8888-62758 [ACK] Seq=7467 Ack=11931449 Win=13056 Len=0 TSsval=226971. 
3260 3.140625 Server Client TCP 8888-62758 [ACK] Seq=7467 Ack=11934345 Win=10176 Len=0 TSval=226971, 
3261 3.140625 Server Client TCP 8888-62758 [ACK] Seq=7467 Ack=11937241 Win=7232 Len=0 TSval=2269712 
3262 3.140625 Server Client TCP 8888-62758 [ACK] Seq=7467 Ack=11940137 Win=4352 Len=0 TSsval=2269712 
3263 3.140625 Server Client TCP 8888-62758 [ACK] Seq=7467 Ack=11943033 Win=1472 Len=0 TSval=2269712 
3264 3.140625 Server Client TCP [TCP Zerowindow]| 8888-62758 [ACK] Seq=7467 Ack=11944497 Len=0 
3265 3.140625 Server Client TCP [TCP Zerowindow]| 8888-62758 [ACK] Seq=7467 Ack=11944529|Win=0| Len=0 
3266 3.160156 Server Client TCP [TCP Zerowindow]| 8888-~62758 [PSH, ACK] Seq=7467 Ack=11944529 

3267 3.167969 server Client TCP TCP Zerowindow]| 8888-~62758 [PSH，ACK] Seq=7743 Ack=11944529 心 


图 8 
9. [TCP window Full] 


当 Wireshatk 在 一 个 包 中 打上 [TCP window Full] 标 志 时 ， 就 表示 这 个 
包 的 发 送 方 已 经 把 对 方 所 声明 的 接收 窗口 耗 尽 了。 以 图 9 为 例 ，Britain 
一 直 声 明 它 的 接收 窗口 只 有 65535， 意 味 着 Middle ”East 最 多 能 给 它 发 送 
65535 字 节 的 数据 而 无 需 确认 ， 即 “在 途 字 节 数 ”最 多 为 65535 字 节 。 妆 
Wireshark 在 包 中 计算 出 Middle East 已 经 有 65535 字 节 未 被 确认 时 ， 就 会 
发 出 此 提示 。 至 于 Wireshark 是 怎么 计算 的 ， 请 参考 本 书 的 《计算 “在 途 
字 节 数 ”》 一 文 。 











No, Time Source Destination Protocol Info 
71 0.392805000 Middle East Britain TCP [TCP Window Full] 64560-12345 [ACK] Seq=202344 Ack=1 
72 0.395142000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=142521 Win=65535 Len=0 
73 0.395219000 Middle East Britain TCP [TCP Window Fu11] 64560-12345 [ACK] Seq=205200 Ack=1 
74 0.397470000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=145377 Win=65535 Len=0 
75 0.397549000 Middle East Britain TCP 64560-12345 [ACK] Seq=208056 Ack=1 
76 0.400139000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=148233 Win=65535 Len=0 
77 0.400218000 Middle East Britain TCP [TCP window Fu11] 64560-12345 [ACK] Seq=210912 Ack=1 
78 0.402431000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=151089 Win=65535 Len=0 


*| Wl 


田 Checksum: Oxa4dc [validation disabled] 
Urgent pointer: 0 
3 [SEQ/ACK analysis] 
[iRTT: 0.040996000 seconds] 





图 9 

[TCP window Full] 很 容易 跟 [TCP zerowindow】] 混淆 ， 实 际 上 它们 
也 有 相似 之 处 。 前 者 表示 这 个 包 的 发 送 方 暂时 没 办 法 再 发 送 数 据 了 ， 后 
者 表示 这 个 包 的 发 送 方 暂时 没 办 法 再 接收 数据 了 ， 也 就 是 说 两 者 都 意味 
0 都 必须 引起 重视 。 

[TCP segment of a reassembled PDUI] 

人 收 到 这 个 提示 ， 肯 定 已 经 在 Edit > Preferences > Protocols TCP 
荣 单 里 局 用 了 Allow sub dissector to reassemble TCP streams。 它 表示 
Wireshark 可 以 把 属于 同一 个 应 用 层 PDU 〈 比 如 SMB 的 Read Response 和 和 
Write ”Request 之 类 ) 的 TCP 包 虚拟 地 集中 起 来 。 如 图 10 所 示 ， 这 一 个 
SMB Read Response 由 39 一 48 号 包 共 同 完成 ， 因 此 Wireshark 在 最 后 一 个 
包 中 虚拟 地 把 所 有 包 集 中 起 来 。 这 样 做 有 个 好 处 ， 就 是 可 以 右键 点 击 图 
10 底 部 的 方 框 ， 选 择 Copy Bytes Printable Text Only， 从 而 复制 整个 
应 用 层 的 PDU。 做 研发 的 al a 


Faer ” | Expeession.. 

Ne Time Source Desination Pretocol info Length 
38 5.011522 Client Server ped" Read AndX ed FiD: Ox004a, 14215 bytes a5 orfser 0 
3 5.013998 Server client Ter [Ter sequent of reassenbled POU) 

40 5.014019 Server Clienr Tor [rcp 3egmnemc of a reassenbled PDU] 
1 5,014024 erver Client TCP [TCP segnent of a or PDOU] 
5,.014028 Server ciient wr [Ter segnent of 3 reasse ed PDU] 
43 5,014033 Server client TC? [Tcp seguent of a reassesbled POU] 
44 5.01403 erver Client Yep [TCP segnent of a a reassenbled PDOU] 
#5 5.014040 Server 《Ce Tr [YCP segnent of reasseabled POU] 
6 5.014044 Server Client Tor [TCP seguent of a reasse nb) ed PDOU] 
47 5,.014047 Server Client TEP [TCP segnent of a eet ed PDU] 
48 5,014050 Server Cilient ad Read Andx Nesponse, FID: OxX004a, 14215 byres 
nas ER 2 bytes e 《10504 bits), 1313 bytes re ee birs) 


Src ed 于 : 0d:07 (00:60:16:3f:0d:07), Veware_al:S8:41 (00:50:56:a1:58:41) | 
i 和 = oroco 1 Version #4, Src Server (10.32.106.73) ， DSt: ny 人 0， 32 1056， 0 
» Transmission Control Protocol sr A445 gq: 14301 2 1913, Len: 1247 

10 Roassonbled TCP Seqner ， #43 ) en WE7 






S01448), S46(1448), 047 (C1448), #4801247)| 






11. [Continuation to#] 

你 看 到 这 个 提示 ， 说 明 已 经 在 Edit-、Preferences -、Protocols -,;TCP 菜 
单 里 关闭 了 Allow sub dissector to reassemble TCP streams。 比 如 图 10 的 那 
些 包 ， 一 关闭 就 变 成 图 11 这 样 。 








No， Time Source Destination Protocol Info 

38 5.011522 Client server SMB Read Andx Request, FID: Ox004a, 14215 bytes at offset 0 

39 5.013998 Server Client SMB Read AndX Response, FID: Ox004a, 14215 bytes 

40 5.014019 Server Client TCP [Continuation to #39] 445-2212 [ACK] Seq=3317 Ack=1913 Win=65535 Len=1448 1 
41 5.014024 Server Client TCP [Continuation to #39] 445-2212 [ACK] Seq=4765 Ack=1913 Win=65535 Len=1448 1 
42 5.014028 Server Client TCP [Continuation to #39] 445-2212 [ACK] Seq=6213 Ack=1913 Win=65535 Len=1448 1 
43 5.014033 Server Client TCP [Continuation to #39] 445-2212 [ACK] seq=7661 Ack=1913 Win=65535 Len=1448 1 
44 5.014037 Server Client TCP [Continuation to #39] 445-2212 [ACK] Seq=9109 Ack=1913 Win=65535 Len=1448 1 
45 5.014040 Sserver Client TCP [Continuation to #39] 445-2212 [ACK] Seq=10557 Ack=1913 Win=65535 Len=1448 
46 5.014044 Sserver Client TCP [Continuation to #39] 445-2212 [ACK] Seq=12005 Ack=1913 Win=65535 Len=1448 
47 5.014047 server Client TCP [Continuation to #39] 445-2212 [ACK] Seq=13453 Ack=1913 Win=65535 Len=1448 

SS 


48 014050 Server Client TCP [continuation to #39] 445-2212 [PSH, ACK] Seq=14901 Ack=1913 Win=65535 Len= 


图 11 

仔细 对 比 图 10 和 图 11， 你 会 发 现 Read Response 在 图 10 中 被 算 在 了 48 
号 包头 上 ， 而 在 图 11 中 被 算 到 了 39 二 包头 上 。 这 样 会 市 来 一 个 诡异 的 结 
果 : 图 10 的 读 啊 应 时 间 为 2.528 毫 秒 〈38 号 包 和 48 号 包 的 时 间 差 )》， 而 
图 11 的 读 啊 应 时 间 为 2.476 写 秒 〈38 号 包 和 39 号 包 的 时 间 差 ) 。 究 竟 哪 
个 算 正 确 呢 ? 这 个 问题 很 难 回答 ， 如 条 在 乎 的 是 实际 的 总 性 能 ， 那 就 看 
前 者 ， 如 有 果 想 忽略 TCP/AP 协 议 的 损耗 ， 单 看 服务 器 的 啊 应 速度 ， 那 惑 看 
后 者 。 在 茶 些 特殊 情况 下 ， 这 两 者 相差 非常 大 ， 所 以 必须 搞 清 楚 。 

12. [Time-to-live exceeded(Fragment reassembly time exceeded)| 

ICMP 的 报错 有 好 多 种 ， 大 都 不 难 理解 ， 所 以 我 们 只 举 其 中 的 一 种 
为 例 。[Fragment reassembly time exceeded] 表 示 这 个 包 的 发 送 方 之 前 收 
到 了 一 些 分 片 ， 但 是 由 于 某 些 原因 迟 迟 无 法 组 装 起 来 。 比 如 在 图 12 中 ， 
由 于 上 海 及 往 北 京 的 一 些 包 被 分 片 传输 ， 且 有 一 部 分 在 路 上 丢失 了 ， 所 
以 北京 方 无 法 组 装 起 来 ， 便 只 好 用 这 个 ICMP 报 错 告知 上 海 方 。 


Fifter: icmp [>| Expression.. Clear Apply Save 





No. Time Source Destination Protocol Info 
404394 117.738399 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404395 117.738399 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404396 117.738399 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404397 117.738399 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404578 117.994370 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
404802 118.762281 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543888 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543889 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543890 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543891 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543892 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543893 200.416848 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
543948 201.440730 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
549061 204.896331 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
549062 204.896331 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 
549063 204.896331 Beijing shanghai ICMP Time-to-live exceeded (Fragment reassembly time exceeded) 


图 12 





|. JWireshark 


Wireshark 是 我 工作 中 最 有 价值 的 工具 之 一 。 这 部 分 的 选材 正 来 自我 
的 工作 经 历 ， 窗 盖 面 偏 窄 〈 因 为 我 已 经 8 年 多 没有 换 工作 了 〉 ， 但 是 比 
较 深入 ， 因 此 建议 阅读 时 放 慢 速度 。 前 4 篇 的 内 容 有 很 强 的 相关 性 ， 之 
所 以 分 开 来 写 而 不 是 合成 一 篇 ， 是 为 了 给 读者 循序 渐进 的 体验 。 其 他 每 
一 篇 都 比较 独立 ， 所 以 遇 到 目 己 不 辟 欢 的 内 容 可 以 直接 路 过 ， 这 不 会 影 
啊 后 面 的 阅读 。 











» 壮 i ‘ 


看 上 去 很 美好 ， 用 了 却 有 上 当 的 感觉 一 一 这 种 心理 落 关 不 仅 存在 于 








淘宝 买 家 秀 。 对 Wireshark 初 学 者 来 说 ， 第 一 次 看 到 网 络 包 的 时 候 也 会 有 
失落 感 ， 甚 至 怀疑 以 前 看 的 书 是 错 的 。 
在 某 些 网 络 书 中 ， 一 个 简单 的 TCP 传 输 过 程 如 图 1 所 示 耳 。 


理想 的 TCP 传 输 





客户 端 服务 占 


图 1 
由 图 1 可 见 ， 客 户 端 每 传 两 个 数据 包 ， 服 务 器 就 立即 Ack 一 下 表示 已 





经 收 到 。 比 如 Ack 3 表示 收 到 了 1 号 和 2 号 两 个 包 ， 正 在 期 待 3 号 包 : Ack 
5 表示 又 收 到 了 3 号 和 4 号 两 个 包 ， 正 在 期 待 5 号 包 。 像 图 1 这 样 美 好 的 景 
象 在 数据 接收 方 〈 即 本 文中 的 服务 器 ) 抓 到 的 包 中 的 确 能 看 到 ， 比 如 图 
2 就 很 符合 。23 号 包 的 “Seq=8413，Len=1448”， 两 者 之 和 恰好 等 于 24 号 
包 的 “Ack=9861”， 所 以 24 号 包 就 是 对 23 号 包 ( 以 及 22 号 包 ) 的 确认 。 有 
兴趣 的 话 可 以 把 图 2 所 有 包 都 对 照 一 下 ， 看 看 是 不 是 非常 吻合 图 1 的 模 
型 。 


Noc， Time Source Destination Protocol Info 








22 15.403709 Client Server TCP [continuation to #16] 2049-703 [ACK] seq=6965 Ack=873 Win=49152 Len=1448 TSVz 
23 15.403938 Client Server TCP [continuation to #16] 2049-~703 [ACK] Seq=8413 Ack=873 Win=49152 Len=1448 TSVi 
24 15.403948 Sserver Client TCP 703-2049 [ACK] seq=873 Ack=9861 Win=843 Len=0 TSval=2234706033 TSecr=63379094 
25 15.403958 Client Server TCP [Continuation to #16] 2049-~703 [ACK] Seq=9861 Ack=873 Win=49152 Len=1448 TSV: 


26 15.404189 Client Server TCP [Continuation to #16] 2049-~703 [ACK] Seq=11309 Ack=873 Win=49152 Len=1448 TS\ 
27 15.404199 Sserver Client TCP 703-~2049 [ACK] Seq=873 Ack=12757 Win=1024 Len=0 TSval=2234706033 TSecr=63379( 
28 15.404208 Client Server TCP [Continuation to #16] 2049-~703 [ACK] Seq=12757 Ack=873 Win=49152 Len=1448 TS\ 
29 15.404438 Client Server TCP [continuation to #16] 2049-703 [ACK] Seq=14205 Ack=873 Win=49152 Len=1448 TS\ 
30 15.404444 Server Client TCP 703-2049 [ACK] Seq=873 Ack=15653 Win=1205 Len=0 TSval=2234706033 TSecr=63379( 
31 15.404449 Client Server TCP [Continuation to #16] 2049-703 [ACK] Seq=15653 Ack=873 Win=49152 Len=1448 TS\ 
32 15.404689 Client Server TCP [Continuation to #16] 2049-~703 [ACK] Seq=17101 Ack=873 Win=49152 Len=1448 TS\ 
33 15.404697 server Client TCP 703-~2049 [ACK] Seq=873 Ack=18549 Win=1386 Len=0 TSval=2234706033 TSecr=63379( 
34 15.404708 Client Server TCP [Continuation to #16] 2049-+703 [ACK] Seq=18549 Ack=873 Win=49152 Len=1448 TS 
35 15.404939 Client Server TCP [Continuation to #16] 2049-703 [ACK] seq=19997 Ack=873 Win=49152 Len=1448 TS\ 
36 15.404948 Server Client TCP 703-2049 [ACK] Seq=873 Ack=21445 Win=1567 Len=0 TSval=2234706034 TSecr=63379( 


图 2 
然而 这 只 是 从 数据 接收 方 的 角度 所 看 到 的 。 要 知道 网 络 上 存在 延 

迟 ， 所 以 在 数据 发 送 方 〈 即 本 文中 的 客户 端 ) 抓 到 的 网 络 包 就 没 这 么 理 
想 了 。 想 象 一 下 ， 同 样 是 图 1 中 的 那些 包 ， 算 上 网 络 延迟 的 传输 过 程 会 
是 什么 样子 的 ? 请 看 图 3， 这 些 Ack 包 到 达 客 户 端 时 会 滞后 一 些 ， 所 以 客 
户 端 发 完 6 号 包 才 收 到 Ack 3， 发 完 8 号 包 才 收 到 Ack 5。 虽 然 看 上 去 有 
点 “ 答 非 所 问 ”， 但 这 是 完全 符合 TCP 协 议 的 。 因 此 建议 初学 者 最 好 两 边 
同时 抓 包 ， 对 照 着 看 ， 以 免 产 生 误解 。 











真实 反映 两 端的 TCP 传 输 








按理 说 图 3 这 种 交叉 矢 线 的 表示 方法 是 最 精确 的 ， 我 在 书 中 为 什么 
很 少 采 用 呢 ? 因为 本 书 介绍 的 是 Wireshark， 而 用 Wireshark 打 开 一 个 包 
只 能 看 到 一 边 的 情况 ， 所 以 我 宁愿 只 站 在 其 中 一 边 的 角度 来 画图 ， 这 样 
会 更 接近 在 Wireshark 中 看 到 的 样子 。 当 然 选 择 哪 一 边 也 很 有 讲究 ， 假 如 
从 一 开始 就 站 在 数据 发 送 方 ( 即 本 文中 的 客户 端 》 的 角度 看 ， 读 者 一 定 
会 觉得 有 点 乱 ， 模 型 图 请 看 图 4。 





实际 在 客户 端 看 到 的 TCP 传 输 





客户 端 服务 器 
图 4 

从 Wireshark 上 看 真实 的 包 就 更 乱 了 ， 图 5 就 是 一 个 在 数据 发 送 方 上 
抓 到 的 包 。 其 中 7 号 包 是 “Seq=263611，Len=249”， 两 者 之 和 263860 远 远 
大 于 8 号 包 的 “Ack=3284”， 可 见 Ack 包 严重 滞后 了 。 我 在 上 一 本 书 中 尽 
量 避 免 引 入 这 样 的 截图 ， 就 是 担心 读者 被 这 迟 来 的 Ack 混 消 了 。 然 而 丑 
媳妇 是 早晚 要 见 公 婆 的 ， 当 我 们 的 研究 深入 到 一 定 程度 ， 两 边 抓 到 的 网 
络 包 都 必须 学 会 面 对 。 有 的 时 候 甚 至 只 能 分 析 看 上 去 混乱 的 那 一 边 ， 接 
下 来 的 两 篇 文章 就 是 这 样 。 
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图 5 
假如 本 文 的 内 容 让 你 觉得 有 点 犯 迷糊 ， 可 能 需要 停 下 来 慢 慢 消化 ， 
甚至 多 读 两 遍 。 理 解 了 这 个 ， 才 能 翻 到 下 一 篇 ， 看 看 如 何 计算 “在 途 字 


Seq=262223 Ack=1 Win=65535 Len=1388 TSval=21; 
Seq=263611 Ack=1 Win=65535 Len=249 TSVvVal1=2121 
Seq=1 Ack=3284 Win=4096 Len=0 TSsval=2955010 - 
Seq=263860 Ack=1 Win=65535 Len=1388 TSval=21.; 
Seq=265248 Ack=1 Win=65535 Len=180 TSsval=212| 
seq=1 Ack=5033 Win=4096 Len=0 TSsval=2955010 - 
Seq=265428 Ack=1 Win=65535 Len=1388 TSval=21.; 
Seq=266816 Ack=1 Win=65535 Len=361 TSval=212| 
Seq=1 Ack=6876 Win=4096 Len=0 Tsval=2955010 - 
Seq=267177 Ack=1 Win=65535 Len=1388 TSval=21; 
Seq=268565 ACck=1 Win=65535 Len=455 TSval=212 
seq=1 Ack=8529 Win=4096 Len=0 Tsval=2955010 - 
Seq=269020 Ack=1 Win=65535 Len=1388 TSVva1=21， 
Seq=270408 Ack=1 Win=65535 Len=265 TSval=212 
Seq=1 Ack=10372 Win=4096 Len=0 TSval=2955010 


| 算 “在 省 字 和 399 


我 一 直 说 记 斯 带 分 .霍金 的 金玉 民 言 一 每 写 一 道 数学 公式 就 会 失 
去 一 半 读 者 。 不 过 为 了 深度 分 析 网 络 包 ， 有 时 候 是 不 得 不 计算 的 ， 好 在 
小 学 一 年 级 的 加 减法 就 够 用 了 。 

网 络 的 承载 量 就 是 一 个 需要 计算 的 值 。 怎 样 理 解 这 个 概念 呢 ? 如 图 
1 所 示 ， 一 架 波 首 747 能 够 承载 上 万 个 小 包裹 ， 而 一 架 无 人 机 只 能 承载 一 
个 ， 这 就 反映 了 它们 不 同 的 承载 量 。 换 个 角度 ， 也 可 以 说 承载 量 就 是 处 
于 运输 工具 中 的 货物 量 ， 即 已 经 从 源 仓库 发 货 ， 但 还 没有 到 达 目 的 地 的 
包 事 数量 。 




















图 1 
和 运输 机 类 似 ， 网 络 承 载 量 也 可 以 用 已 经 发 送出 去 ， 但 尚未 被 确认 





的 字 市 数 来 表示 。 在 英文 搁 术 文档 中 ， 形 象 地 用 “bytes in 人 flight" 来 描述 
它 ， 我 觉得 用 “在 途 字 市 数 ” 来 翻译 最 好 。 

飞机 如 果 超 载 了 ， 有 是 会 发 生 严 重 事故 的 。 而 在 途 字 节 数 如 果 超 过 网 
络 的 承载 能 力 ， 也 会 丢 包 重 传 ， 这 吏 是 我 们 需要 计算 它 的 原因 。 怎 么 计 
算 呢 ? 假如 网 络 上 只 有 一 个 ICP 连 接 在 通信 ， 那 么 还 可 以 通过 带宽 和 延 
迟 来 计算 最 多 能 承载 多 少 在 途 字 节 数 。 而 实际 环境 往往 如 图 2 所 示 ， 同 
一 条 网 络 路 径 是 由 多 台 主 机 之 间 共 享 的 ， 根 本 不 知道 多 少 比例 的 带宽 是 








分 配给 茶 个 TCP 连 接 。 这 时 候 束 裔 要 用 到 网 络 神 右 Wireshark 来 分 析 了 。 


网 络 路 径 





] > 一 
3) 
图 2 
分 析 之 前 要 先 抓 包 。 应 该 在 哪 一 端 抓 呢 ?” 我 们 先 两 边 都 尝试 一 下 。 
上 文 《 书 上 错 了 吗 ? 》 已 经 交代 过 ， 网 络 延 迟 会 导致 同样 的 网 络 包 在 两 
端 体现 出 不 同 的 顺序 ， 并 用 下 面 的 图 3 演示 。 





真实 反映 两 端的 TCP 传 输 





客户 端 服务 器 


图 3 

我 在 图 3 的 服务 器 上 随机 挑选 一 个 时 间 点 并 标志 为 T1。 由 于 服务 器 
在 该 点 之 前 收 到 8 号 包 并 立即 回复 了 “Ack 9”( 表 示 9 号 之 前 的 包 都 收 到 
了 ) ， 所 以 在 途 字 市 数 为 0。 也 就 是 说 ， 在 数据 接收 方 抓 的 包 里 是 看 不 
到 在 途 字 市 数 的 ， 没 有 分 析 音 义 。 

接着 我 在 图 3 的 客户 端 随机 挑选 一 个 时 间 点 并 标志 为 T2， 由 于 在 该 
时 间 点 之 前 10 号 包 已 经 发 出 去 ， 但 收 到 的 “Ack 7” 只 表示 7 号 之 前 的 包 都 
收 到 了 ， 也 即 意味 着 7、8、9、10 号 包 都 还 没有 确认 ， 所 以 在 途 字 节 数 
就 是 这 4 个 包 所 携 市 的 数据 量 。 这 说 明 在 数据 发 送 方 抓 到 的 包 才 能 用 来 
分 析 在 途 字 节 数 。 

从 模型 图 中 理解 了 原理 ， 接 下 来 就 可 以 用 Wireshark 来 分 析 真 实 的 包 





了 。 图 4 是 在 客户 端 (数据 发 送 方 ) 抓 到 的 ， 如 果 我 们 想 知 道 第 


0.400000 秒 时 的 在 途 字 节 数 ， 应 该 如 何 计 算 呢 ? 
N 





Time Source Destination Protocol Info 

6 0.000000 Client server TCP 65096-~8888 [ACK] Seq=262223 Ack=l1 Win=65535 Len=1388 TSVval=2] 
7 0.000000 Client server TCP 65096-~8888 [ACK] seq=263611 Ack=1 Win=65535 Len=249 TSval=21: 
8 0.339843 Server Client TCPp 8888-65096 [ACK] seq=1 [ck=3284] win=4096 Len=0 Tsval=2955010 


9 0.339843 Client server TCP 65096--8888 [ACK] seq=263860 Ack=l Win=65535 Len=1388 TSVval=2] 
10 0.339843 Client Sserver TCcPp 65096-8888 [ACK] Ee hck- win=65535 [Cen=130] Tsval=21: 
11 0.457031 server Client TCP 8888-65096 [ACK] Seq=1 Ack=5033 Win=4096 Len=0 TSval=2955010 
12 0.457031 Client Server TCcPp 65096-8888 [ACK] Seq=265428 Ack=1 Win=65535 Len=1388 TSval=2]j 
13 0.457031 Client server TCP 65096-~8888 [ACK] Seq=266816 Ack=l Win=65535 Len=361 TSval=21: 
14 0.589843 Server Client TCPp 8888-65096 [ACK] seq=1 Ack=6876 Win=4096 Len=0 TSval=2955010 
图 4 

在 该 时 间 点 之 前 客户 端 发 送 的 是 10 号 包 ， 即 “Seq=265248， 
Len=180” 字 节 ， 表 示 序 号 在 265248+180=265428 之 前 的 字 节 已 经 发 送出 
去 了 。 而 第 0.400000 秒 之 前 服务 器 的 Ack 为 3284， 表 示 序 号 在 3284 之 前 
的 字 节 已 经 收 到 了 。 那 么 在 途 字 节 数 就 是 265428-3284=262144 字 节 。 如 
果 要 归纳 出 一 条 公式 ， 可 以 表示 成 : 

在 途 字 节 数 =Seq+Len-Ack 

其 中 Seq 和 Len 是 来 自 上 一 个 数据 发 送 方 的 包 ， 而 Ack 则 来 自 上 一 个 
数据 接收 方 的 包 。 我 们 再 拿 第 0.500000 秒 来 练习 一 下 ， 套 用 公式 可 以 算 
出 在 途 字 节 数 应 该 是 266816+361-5033=262144， 与 第 0.400000 秒 的 一 样 
多 。 

理解 了 在 途 字 节 数 的 计算 方式 ， 惑 可 以 翻 到 下 一 篇 《估算 网 络 拥 宕 
点 》 Ta 要 是 还 不 太 理 解 ， 建议 多 读 两 遍 。 


9 


























前 两 篇 写 了 那么 多 ， 其 实 都 是 为 了 给 本 文 的 话题 作 铺 垫 。 这 个 话题 
就 是 网 络 拥塞 点 当 发 送 方 一 口气 向 网 络 中 注入 大 量 数据 时 ， 就 可 能 
超过 该 网 络 的 承受 能 力 而 导致 拥塞 ， 这 个 足以 触发 拥塞 的 数据 量 束 称 大 
拥塞 点 _ 思 。 从 定义 上 看 ， 拥 塞 点 和 上 文 所 介绍 的 “在 途 字 节 数 ?是 不 是 
有 关系 呢 ? 

确实 有 关系 。 假 如 把 网 络 路 径 想 象 成 一 条 河流 ， 发 送 方 是 水 源 ， 接 
收 方 是 入 海口 ， 那 在 途 字 节 数 就 是 河 里 的 水 量 。 当 水 源 的 流速 超过 了 入 
海口 的 流速 ， 河 里 的 水 量 就 会 越 来 越 多 ， 直 至 溢出 。 所 以 大 致 可 以 认 
为 ， 发 生 拥 考 时 的 在 途 字 贡 数 即 是 该 时 刻 的 网 络 拥 赛 点 。 明 白 了 这 一 
点 ， 估 算 拥 窗 点 就 可 以 简化 成 找 出 拥 罕 时 刻 的 在 途 字 节 数 了 。 

那 又 如 何在 Wireshark 中 找到 拥 窄 时刻 呢 ?众所周知 ， 拥 罕 的 特征 是 
连 串 丢 包 ， 丢 包 之 后 束 会 重 传 ， 而 Wireshark 是 能 够 标识 出 重 传 包 的 。 
此 我 们 可 以 根据 这 个 规律 来 寻找 : 先 从 Wireshark 中 找到 一 连 串 重 传 包 中 
的 第 一 个 ， 再 根据 该 重 传 包 的 Seq 值 找到 其 原始 包 ， 最 后 计算 该 原始 包 
发 送 时 刻 的 在 途 字 节 数 。 由 于 网 络 拥塞 就 是 在 该 原始 包 发 出 去 的 时 刻 发 
生 的 ， 所 以 这 个 在 途 字 节 数 就 大 致 代 表 了 拥堵 点 的 大 小 。 

具体 操作 步骤 如 下 。 

1. 在 Wireshark 上 单 击 Analyze 荣 单 ， 再 单 击 Expert Info 选项， 得 到 
图 1 的 重 传统 计 表 。 



































Errors: 3 (2390) | Warnings: 3 (159) | Notes: 121 (4538) |Chats:0 (0) | Details: 7087 | Packet Comments: 0 


Group 4 Protocol 4 Summary 4 Count 
日 Sequence TCP Retransmission (suspected) 

Packet: 1225 

Packet: 
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图 1 
2. 点 击 第 一 个 重 传 包 No.1225， 可 见 它 的 Seq=1012852。 于 是 


用 “tcp.seq==1012852” 作 为 过 滤 条 件 ， 见 图 2。 











Filter | tcp.seq == 1012852 [=] Expression.. Clear Apply Save 

No. Time Source Destination Protocol Info 

1225 0.937500 Client Server TCP [TCP Retransmission] 49454 > ddi-tcp-1 [ACK] seq=1012852 Ack=1105 
1226 0.937500 Server Client TCP [TCP Dup ACK 1171#51] ddi-tcp-1 > 49454 [ACK] seq=1105 Ack=991851 
1227 0.937500 Client Server TCP [TCP Retransmission] 49454 > ddi-tcp-1 [ACK] seq=1026650 Ack=1105 
1228 0.937500 server Client TCP [TCP Dup ACK 1171#52] ddi-tcp-1 > 49454 [ACK] Seq=1105 Ack=991851 
1229 0.937500 Client Server TCP [TCP Retransmission] 49454 > ddi-tcp-1 [ACK] Seq=1033235 Ack=1105 


1230 0.941406 server Client TCP [TCP Dup ACK 1171#53] ddi-tcp-1 > 49454 [ACK] Seq=1105 Ack=991851 
4 加 








日 Transmission Control Protocol, Src Port: 49454 (49454), Dst Port: ddi-tcp-1 (8888) ，seq: 1012852，Ack: 1105, 
Source port: 49454 (49454) 
Destination port: ddi-tcp-1 (8888) 
[stream index: 0] 














Sequence number: 1012852 (relative sequence number) 

[Next sequence number: 1013668 (relative sequence number)] 

Acknowledgment number: 1105 (relative ack number) 

图 2 
人 
， 点击 Apply 过 滤 之 后 得 到 了 原始 包 No.1053， 见 图 3。 

Filter: 过 == 1012852 [= bpresson- Clear Appy Saves 
No. Time Source Destination Protocol Info 
1053 0.804688 Client Server TCP 49454 > ddi-tcp-1 [ACK] Seq=1012852 Ack=1105 Win=32768 Len=816 TS 
1225 0.937500 Client server TCP [TcP Retransmission] 49454 > ddi-tcp-1 [ACK] seq=1012852 Ack=1105 
< 





日 Transmission Control Protocol, Src Port: 49454 4 CGA5AY, Dst Port: i C8588)， seq: 1012852，Ack: 1105, 
Source port: 49454 (49454) 


Destination port: ddi-tcp-1 (8888) 

[stream index: 0] 

Sequence number: 1012852 (relative sequence number) 

[Next sequence number: 1013668 (relative sequence number)] 
Acknowledgment number: 1105 (relative ack number) 


图 3 
4. 选 定 1053 号 包 ， 然 后 点 击 Clear 清 除 过 滤 。 可 见 上 一 个 来 自 服务 
端的 包 是 1051 号 包 ， 见 图 4。 





























Filter v | Expression... Clear Apply Save 





No. Time Source Destination Protocol Info 

1051 0.804688 Server Client TCP ddi-tcp-1 > 49454 [ACK] Seq=1105 Ack=910546 Win=2457 Len=0 TSval=24415168 TSecr= 
1052 0.804688 Client Server TCP 49454 > ddi-tcp-1 [ACK] Seq=1011404 Ack=1105 Win=32768 Len=1448 TSval=41365538 TI! 
1053 0.804688 Client Server TCP 49454 > ddi-tcp-1 [ACK] Seq=1012852 Ack=1105 Win=32768 Len=816 TSval=41365538 TS! 
* 吕 


Transmission Control Protoco1，Src Port: 49454 (49454), Dst Port: ddi-tcp-1 (8888), Seq: 1012852，Ack: 1105, Len: 816 


图 4 

5. 利用 上 文 《 计 算 “ 在 途 字 节 数 ”》 的 公式 ， 可 知 当 时 的 在 途 字 节 
数 为 1012852 (No.1053 的 Seq) +816 (No.1053 的 
Len) -910546 (No.1051 的 Ack) =103122 字 节 。 

就 这 样 ， 该 时 刻 的 拥塞 点 被 估算 出 来 了 。 这 个 方法 不 一 定 很 精确 ， 
但 是 绝对 有 参考 意义 。 我 们 最 好 多 次 采样 ， 然 后 选 定 一 个 合适 的 值 作 为 
该 连接 的 拥塞 点 。 什 么 样 的 值 才 算 合适 ? 我 个 人 认为 不 应 该 取 平 均值 ， 
而 应 该 取 一 个 偏 小 的 。 比 如 说 10 次 采样 中 有 5 次 是 32KB，5 次 是 40KB， 
那 宁 愿 把 拥塞 点 定 为 32KB， 而 不 是 平均 值 36KB。 

为 什么 要 如 此 保守 呢 ? 这 得 从 估算 拥塞 点 的 目的 开始 说 起 。 我 们 六 
注 杏 兰 地 估算 它 ， 是 为 了 能 把 发 送 窗 口 限 制 在 这 个 拥塞 点 以 下 ， 从 而 避 
免 拥 塞 ， 提 高 传输 性 能 。 限 制 在 32KB 以 下 时 可 以 完全 消除 拥塞 ， 而 假 
如 取 了 个 平均 值 36KB， 那 就 只 能 减少 二 分 之 一 的 拥塞。 我 在 上 一 本 书 
中 己 经 详细 分 析 过 ， 每 一 次 拥 窄 市 来 的 性 能 影响 都 很 大 ， 即 使 干 分 之 一 
的 概率 都 足以 导致 性 能 大 滑坡 ， 保 守 一 点 还 是 值得 的 。 人 至 于 估算 结束 
后 ， 如 何在 系统 中 把 窗口 限制 在 拥塞 点 以 下 ， 不 同 的 操作 系统 有 不 同 的 
方法 ，Windows 环 境 可 以 参考 KB 224829 的 步骤 。 

















当 你 开始 动手 估算 网 络 的 拥塞 点 ， 很 可 能 会 遇 到 一 个 诡异 的 现象 ， 
比如 下 面 这 个 例子 。 

我 找到 了 一 个 重 传 包 的 序号 为 491， 其 Seq 号 为 349974， 便 以 此 作为 
过 滤 条 件 ， 如 图 1 所 示 。 


Fiter | tcp.seq == 349974 加 Expression... Clear Apply Save 





No. Time Source Destination Protocol Info 

| 491 7.425781 Client Server TCP [TCP Fast Retransmission] 65096-8888 [ACK] Seq=349974 Ack=277 W 
492 7.425781 Server Client TCP [TCP Dup ACK 486#4] 8888-65096 [ACK] Seq=277 Ack=349974 Win=409 
493 7.425781 Server Client TCP 8888-65096 [ACK] Seq=277 Ack=351362 Win=4096 Len=0 TSval=295503 
4 | [0 








日 Transmission Control Protocol, Src Port: 65096 (65096), Dst Port: 8888 (8888), Seq: 349974, Ack: 277 
source Port: 65096 (65096) 
Destination Port: 8888 (8888) 
[Stream index: 0] 
[TCP Segment Len: 1388] 
sequence number: 349974 (relative sequence number) 
[Next sequence number: 351362 (relative sequence number)] 
Acknowledgment number: 277 (relative ack number) 


图 1 
点 击 Apply 过 小 ， 可 是 结果 却 只 见 重 传 包 ， 不 见 原始 包 ， 如 图 2 所 
示 。 是 什么 原因 导致 了 这 个 现象 呢 ? 


Filter: tcp.seq == 349974 [=| gpression- Clear Apply Save 











No. Time Source Destination Protocol Info 
491 7.425781 Client Server TCP [TCP Fast Retransmission] 65096-~8888 [ACK] Seq=349974 Ack=277 Win=65535 Len=1388 





«| 咱 


日 Transmission Control Protoco1，Src Port: 65096 (65096), Dst Port: 8888 (8888), Seq: 349974, ACk: 277, Len: 1388 
Source Port: 65096 (65096) 
Destination Port: 8888 (8888) 
[stream index: 0] 
[TcP segment Len: 1388] 
Sequence number: 349974 (relative sequence number) 
[Next sequence number: 351362 (relative sequence number)] 
Acknowledgment number: 277 (relative ack number) 


图 2 





一 般 有 下 面 3 个 可 能 : 
.这 个 包 是 在 接收 方 抓 的 ， 看 不 到 已 经 在 路 上 丢失 的 原始 包 是 正常 





的 ; 





:开始 抓 包 的 时 候 ， 原 始 包 已 经 传 完 了 ， 看 不 到 它 也 是 合理 的 ; 


"Wireshark 出 了 bug， 把 一 个 正常 包 标 记 成 LTCP Fast 
Retransmission | 了 。 

不 过 我 遇 到 的 情况 并 不 符合 这 3 个 可 能 。 原 始 包 实际 上 已 经 抓 到 
了 ， 只 是 用 它 的 Seq 号 过 滤 不 出 来 而 已 。 

我 是 怎么 知道 原始 包 已 经 抓 到 的 呢 ? 请 看 图 3， 我 把 过 滤 条 件 改 
成 “tcp.seq<349974”， 发 现 客户 端 最 后 发 送 的 一 个 包 是 “Seq=348586， 
Len=2776”， 正 好 包含 了 我 们 想 要 寻找 的 原始 包 “Seq==349974， 
Len=1388” 的 所 有 字 节 。 


Filter: | tcp.seq < 349974 [= | Expression... Clear Apply Save 


No. Time Source Destination Protocol Info 
129 3.023437 Client Server TCP 65096~8888 [ACK] Seq=348586 Ack=l Win=65535 Len=2776 


LL 


3 Transmission Control Protocol, src Port: 65096 (65096), Dst Port: 8888 (8888), Seq: 348586, 
source Port: 65096 (65096) 
Destination Port: 8888 (8888) 
[stream index: 0] 
[TCP segment Len: 2776] 


Sequence number: 348586 (relative sequence number) 
[Next sequence number: 351362 (relative sequence number)] 
Acknowledgment number: 1 (relative ack number) 

图 3 


我 一 开始 觉得 很 奇怪 ， 这 个 TCP 连 接 的 MSS (最 大 数据 段 长 度 ) 是 
1388， 怎 么 会 有 Len=2776 〈 即 1388 的 两 倍 ) 的 包 出 现 呢 ? 后 来 读 到 了 
Wikipedia 上 的 一 个 条 目 ， 才 知道 这 就 是 传说 中 的 LSO (Large Segment 
Offload) 。 目 前 我 还 没有 上 听 到 过 “ 信 达 雅 ” 的 翻译 ， 所 以 还 是 以 LSO 来 称 
呼 它 吧 。 

LSO 是 什么 呢 ? 它 是 为 了 拯救 CPU 而 出 现 的 一 个 创意 。 随 着 网 络 进 
入 干 兆 和 万 兆 时 代 ，CPU 的 工作 负担 明显 加 重 了 。625MB/s 的 网 络 流量 
大 约 需 要 耗费 5 GHz 的 CPU， 这 已 经 需要 一 个 双核 2.5 GHz CPU 的 全 部 处 
理 能 力 了 。 为 了 绥 解 CPU 的 压力 ， 最 好 把 它 的 一 些 工作 外 包 《〈offload ) 
给 网 卡 ， 比 如 TCP 的 分 段 工作 。 

传统 的 网 络 工 作 方式 是 这 样 的 : 应 用 层 把 产生 的 数据 交 给 TCP 层 ， 
TCP 层 再 根据 MSS 大 小 进行 分 段 〈 由 CPU 负责 ) ， 然 后 再 交 给 网 卡 。 而 








启用 LSO 之 后 ，TCP 层 就 可 以 把 大 于 MSS 的 数据 块 直接 传 给 网 卡 ， 让 网 
卡 来 负责 分 段 工 作 了 。 比 如 本 例子 中 的 “Seq=348586，Len=2776”， 最 后 
会 被 网 卡 分 成 “Seq=348586，Len=1388” 和 “Seq=349974，Len=1388” 两 个 
包 。 由 于 在 发 送 方 抓 包 时 相当 于 站 在 CPU 的 视角 ， 所 以 看 到 的 是 一 个 分 
段 前 的 大 包 。 假 如 是 在 接收 方 抓 包 ， 就 是 网 卡 分 段 后 的 两 个 小 包 了 __B 
。 本 文 用 到 的 这 个 例子 还 是 比较 小 的 数据 块 ， 我 还 经 常 抓 到 比 这 个 大 十 
倍 以 上 的 。 前 几 天 @ 阿 里 技术 保障 还 在 微 博 上 发 了 一 篇 文章 ， 也 介绍 
了 这 个 技术 。 

在 过 去 几 年 中 ， 我 经 常 在 估算 拥塞 点 时 遭遇 LSO， 这 就 需要 先 想象 
出 它 分 段 后 的 样子 ， 然 后 再 用 老 办 法 计算 。 我 也 有 过 多 次 利用 LSO 做 性 
能 调 优 的 经 历 ， 比 如 VMware 上 的 虚拟 网 卡 有 时 候 是 性 能 庆 贷 ， 关 闭 
LSO 反 而 性 能 会 更 好 。LSO 的 配置 方式 很 简单 ，Windows 上 只 需要 在 网 
卡 的 高 级 属性 中 找到 Large Send Offload 项 就 行 了 ( 见 图 4) 。 





The following properties are available for this network adapter. Click 
the property you want to change on the left, and then select its value 


end Offload V2 (IPv®) 





熟 读 RFC 





我 在 离开 交大 之 前 ， 特 意 从 校内 FTP 下 载 了 很 多 资料 ， 包 括 RFC 文 
档 。 其 实 当时 并 没有 阅读 它们 的 打算 ， 只 是 想 存 在 电脑 里 ， 以 备 不 时 之 
需 。 不 过 工作 了 几 年 后 ， 我 开始 意识 到 RFC 不 只 是 用 来 检索 的 。 对 于 最 
棘手 的 那 部 分 网 络 问 题 ， 有 时 必须 见 谈 RFC 才 能 解决 ， 我 手头 就 有 很 多 
例子 可 以 证 明 这 一 点 。 

老 油条 的 工程 师 都 知道 ， 性 能 问题 是 最 难 的 ， 因 为 没有 任何 报错 可 
以 入 手 ， 我 们 就 来 说 一 个 性 能 相关 的 架 例 吧 。 有 家 公司 跟 我 反映 过 这 样 
一 个 问题 ， 他 们 的 客户 端 发 数据 到 国外 服务 器 时 非常 乙 。 慢 到 什么 程度 
呢 ? 连 期 望 值 的 一 半 都 达 不 到 ， 就 像 你 家 里 租 了 100M 市 宽 ， 但 实际 用 
起 来 却 不 到 5M 的 效果 ， 肯 定 会 不 满意 。 现 实 中 这 类 问题 往往 是 这 样 收 
场 的 : 

-用户 癌 运 营 丙 投诉 市 宽 不 足 ; 

:运营 商用 测速 工具 自 证 清白; 

:用 户 掏 钱 租 用 更 多 带宽 。 

其 实用 不 着 多 人 花 钱 ， 用 Wireshark 仔 细 分 析 一 下 ， 基 本 都 能 找到 提升 
性 能 的 方法 。 我 先 在 客户 端 抓 了 个 包 ， 然 后 尝试 了 惯用 的 三 板 莽 。 

1. 在 Wireshark 的 Analyze ~ Expert Info -Notes 某 单 中 看 到 图 1 的 重 
传统 计 ， 上 万 个 包 中 只 有 7 个 需要 重 传 ， 比 例 不 算 高 。 


























Group Protocol 4 Summary 

由 Sequence TCP This frame is a (suspected) retransmission 
由 Sequence TCP Duplicate ACK (#3) 

由 Sequence TCP Duplicate ACK (#4) 





四] Limit to display filter 








图 1 
点 击 一 个 来 自 服 务 器 的 Ack 查 看 往返 时 间 CRTT) 。 由 图 2 底部 
可 见 ， 大 概 是 78 室 秒 。 我 随机 点 击 了 很 多 个 Ack， 都 差不多 是 这 个 值 。 





No, Time Source Destination Protocol Info 
63 0.394531000 Client server TCP 58512-8888 [ACK] Seq=699075 Ack=829 Win=65535 Len=38304 
64 0.394531000 Client server TCP 58512-8888 [ACK] Seq=737379 Ack=829 Win=65535 Len=1000 


65 0.394531000 Server Client TCP 8888-58512 [ACK] Seq=829 Ack=630006 Win=19660 Len=0 TSV 
| Wh 











” 国 Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
日 [SEQ/ACK analysis] 
This is an ACK to the segment i 


[The RTT to ACK the segment was: |0. ET seconds] 
图 2 


收集 完 这 些 信息 就 可 以 初步 分 析 了 : 丢 包 不 多 ，RTT 也 很 稳定 ， 但 
数据 却 传 不 快 。 难 道 是 客户 端的 TCP 发 送 窗口 太 小 了 吗 ? 说 到 这 里 就 需 
要 补充 点 基础 知识 了 : 决定 客户 端 太 送 窗 口 的 因素 有 两 个 ， 分 别 为 网 络 
上 的 拥塞 窗口 (Congestion Window， 缩 写 为 cwnd) 和 服务 器 上 的 接收 
窗口 。 后 者 与 本 案例 无 关 〈 已 经 大 到 可 以 忽略 ) ， 而 且 在 本 书 的 《技术 
与 工龄 》 一 文中 详细 介绍 了 ， 这 里 束 不 再 壮 述 。 本 文 要 讲 的 是 更 有 技术 
含量 的 cwnd， 学 过 TCP 协 议 的 工程 师 都 知道 ，cwnd 的 增长 方式 是 先 “ 慢 
启动 ”然后 再 进入 “拥塞 避免 ?。 前 者 起 点 低 但 能 快速 增长 ， 后 者 起 点 
高 ， 但 是 每 个 RTT 只 能 增加 一 个 MSS (Maximum Segment Size， 表 示 一 
个 TCP 包 所 能 携带 的 数据 量 ) 。 在 坐标 轴 中 是 这 样 表示 cwnd 的 增长 过 程 
的 ， 见 图 3。 


















Time 


图 3 
了 解 完 基础 知识 ， 我 们 再 回头 看 看 Wireshark 里 的 cwnd。 选 中 一 个 
发 送 窗口 中 最 后 的 那个 包 ， 束 可 以 看 到 它 的 “Bytes in flight*， 它 在 本 案 
例 中 就 代表 了 cwnd 的 大 小 。 我 随机 选中 了 1970 号 包 ， 从 图 4 可 见 其 cwnd 
为 76020。 根 据 图 3 的 理论 ， 如 果 当 时 处 于 “拥塞 避免 > 阶段 ， 那 下 一 个 
cwnd 应 该 就 是 76020 加 上 一 个 MSS〈 以 太 网 中 大 概 为 1460 字 节 ) ， 变 成 
77480。 如 果 是 在 慢 局 动 阶段 ， 那 就 远 远 不 止 这 么 大 。 





No, _ Time Source Destination Protocol Info 


1969 17.437500000 Client Server TCP 58512-8888 [ACK] Seq=24207689 Ack=25393 Win=65535 Le 
Es7017.437500000 client server TCP 58512-8888 [ACK] Seq=24225473 Ack=25393 Win=65535 Le 
1971 17.449219000 server Client © TCP 8888-58512 [PSH, ACK] Seq=25393 Ack=24150038 win=196 
1972 17. 515625000 server Client © Tcp 8888-58512 [ACK] seq=25669 Ack=24207494 Win=19660 Le 
1973 17.515625000 Client Server TCP 58512-8888 [ACK] Seq=24226058 Ack=25669 Win=65535 Le 
1974 17. 515625000 Client Server TCP 58512-8888 [ACK] seq=24283514 Ack=25669 Win=65535 Le 
1975 17. 515625000 server Client TCP 8888-58512 [ACK] seq=25669 Ack=24226058 Win=19660 Le 





4 | Tm 





Urgent pointer: 0 
田 Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
5 [SEQ/ACK analysis] 
[Bytes in flight: 76020] 


图 4 
然而 再 看 图 5，Wireshark 中 却 显 示 下 一 个 RTT 〈1974 号 包 ) 的 cwnd 
为 76215。 也 就 是 说 经 历 了 一 个 RTT 之 后 才 增 加 了 195 个 字 节 ， 远 不 如 我 
们 所 期 望 的 。 我 接着 又 往 下 看 了 几 个 RTT， 还 是 一 样 的 情况 。 这 意味 着 
客户 端的 发 送 窗 口 增 长 非常 慢 ， 所 以 传输 效率 就 很 低 。 








No， Time Source Destination Protocol Info 

1969 17.437500000 Client Sserver TCP 58512-8888 [ACK] Seq=24207689 Ack=25393 Win=65535 
1970 17.437500000 client server TCP 58512-8888 [ACK] Seq=24225473 Ack=25393 Win=65535 
1971 17.449219000 server Client TCP 8888-58512 [PSH, ACK] Seq=25393 Ack=24150038 Win=] 
1972 17.515625000 server Client TCP 8888-58512 [ACK] Seq=25669 Ack=24207494 Win=19660 
1973 17.515625000 Client server TCP 58512-8888 [ACK] Seq=24226058 Ack=25669 Win=65535 
17.515625000 Client server TCP 58512-8888 [ACK] Seq=24283514 Ack=25669 Win=65535 
1975 17.515625000 server Client TCP 8888-58512 [ACK] Seq=25669 Ack=24226058 Win=19660 





4 | 吕 

Urgent pointer: U 
田 Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
Ss [SEQ/ACK analysis] 









Bytes 1n ignt: 76215 


图 5 
性 能 兰 的 原因 终于 找到 了 ， 但 是 客户 端 为 什么 会 有 这 种 诡异 的 表现 
呢 ? 更 神奇 的 是 ， 同 样 的 客户 端 发 数据 给 其 他 服务 器 束 没 有 这 个 问题 ， 
因此 我 们 还 不 能 把 问题 根源 定位 到 客户 端 上 。 当 你 百 思 不 得 其 解 的 时 
候 ， 最 好 是 去 代码 里 看 看 cwnd 的 计算 方式 是 不 是 有 问题 。 但 如 果 没 有 客 
户 并 的 代码 ， 或 者 根本 看 不 懂 代 码 呢 ? 熟 读 RFC 的 优势 就 体现 出 来 了 。 
在 RFC5681 中 讲 到 了 多 种 cwnd 的 计算 方式 ， 其 中 有 一 种 是 这 样 的 : 


Another common formula that a TCP MAY use to update cwnd during 











congestion avoidance is given in equation (3): 
cwnd+=MSS*MSS/cwnd (3) 
早 看 公式 不 太 容 易 理 解 ， 用 人 话 解 释 一 下 就 是 这 样 的 :假如 客户 端 


的 当前 cwnd 大 小 为 n 个 MSS， 它 就 会 在 一 个 窗口 里 发 出 去 n 个 包 ， 然 后 期 
望 收 到 n 个 Ack。 每 收 到 1 个 Ack 它 就 把 ewnd 增 加 “MSS*MSS/cwnd”， 于 
是 收 到 n 个 Ack 之 后 就 总 共 增 加 了 “MSS*(n*MSS/cwnd)”。 由 于 cwnd 等 于 
n 个 MSS， 所 以 括号 里 的 m0*MSS/cwnd) 大 约 等 于 1， 从 而 实现 了 每 经 过 1 
个 RTT 就 增加 1 个 MSS 的 目的 。 

假如 客户 端 采用 的 就 是 这 个 算法 ， 那 的 确 是 可 能 导致 cwnd 增 长 过 慢 
的 ， 因 为 它 只 有 在 收 到 n 个 Ack 的 情况 下 才能 按 预期 增长 ， 而 世界 上 并 非 
每 台 服 务 器 都 是 收 到 n 个 数据 包 束 回复 n 个 Ack 的 。 我 实验 室 中 的 Linux 服 
务 器 就 是 累计 收 到 两 个 数据 包 才 Ack 一 次 ， 这 就 意味 着 客户 端 每 经 过 1 个 
RIT 只 能 增长 2 个 MSS。 可 是 即使 这 样 也 比 我 手头 的 案例 好 得 多 啊 ， 

195 个 字 节 还 不 到 1/7 个 MSS 呢 。 这 说 明 Ack 的 频率 非常 之 低 ， 在 
Wireshark 里 也 很 容易 证 实 这 一 点 。 

于 是 这 个 问题 就 转换 为 如 何 提高 服务 器 的 Ack 频 率 了 。 几 番 搜 索 之 
后 ， 我 们 发 现 这 台 服 务 器 的 网 卡 上 启用 了 Large Receive 
Offload (LRO) ， 会 积累 多 个 TCP 包 再 集中 处 理 ， 因 此 Ack 数 就 比 别 的 
服务 器 少 很 多 ， 这 也 解释 了 为 什么 其 他 服务 器 没有 性 能 问题 。 后 来 系统 
管理 员 用 ethtool 命 令 关 闭 LRO 就 把 问题 解决 掉 了 。 

总 结 下 来 ， 本 案例 中 的 客户 端 采用 了 一 种 不 太 科 学 的 cwnd 算 法 ， 服 
务 器 上 又 启用 了 LRO。 两 者 分 开工 作 的 时 候 都 没有 问题 ， 但 是 配合 起 来 
就 会 导致 cwnd 上 升 过 慢 ， 从 而 极 大 地 影响 了 性 能 。 这 类 问题 如 果 没 有 
Wireshark， 我 们 估计 都 无 法 定位 ， 而 如 果 不 熟 恋 RFC， 就 算 用 上 
Wireshark 也 不 知道 如 何 解决 。 就 像 武侠 小 说 里 的 内 力 和 剑 法 一 样 ， 两 者 
都 很 重要 。 




















一 个 你 本 该 能 解决 的 问题 

很 多 年 来 ，IT 公 司 的 笔试 试卷 中 都 有 这 样 一 道 送 分 题 一 一 列举 TCP 
和 UDP 的 差别 。 我 过 到 过 的 应 聘 者 或 多 或 少 都 能 管 出 重点 ， 比 如 TCP 是 
可 靠 的 ，UDP 是 不 可 靠 的 ， 等 等 ， 有 些 甚 至 能 把 教材 中 的 段落 原封 不 动 
地 写 出 来 。 

不 过 我 最 近 开 始 怀疑 这 道 笔试 题 的 价值 ， 因 为 很 多 人 似乎 是 死记 便 
背 的 ， 完 全 不 理解 答案 的 真正 含义 。 就 算 有 部 分 人 说 得 出 个 所 以 然 ， 也 
不 知道 如 何 运 用 。 本 文 要 分 享 的 案例 ， 就 是 关于 TCP 和 UDP 的 差别 。 

故事 的 背景 是 这 样 的 ， 某 公司 的 主 数据 中 心 设 在 上 海 ， 通 过 网 络 把 
数据 同步 到 北京 的 镜像 ， 每 10 分 钟 同步 一 次 。 项 目 实施 时 规划 得 很 好 ， 
租用 的 带宽 经 过 严密 计算 所 以 理论 上 完全 满足 需求 ， 也 用 FTP 传 输 验 证 
过 了 。 可 是 不 知道 为 什么 ， 实 施 后 却 无 法 在 10 分 钟 内 完成 数据 同步 。 实 
施 团队 驻 场 数 天 都 没有 解决 ， 只 能 怀疑 租用 的 宽 珊 质量 有 问题 ， 于 是 就 
和 网 络 提供 商 陷 入 了 无 休止 的 扯皮 。 

到 最 后 实在 走投无路 了 ， 项 目 组 决定 抓 一 个 网 络 包 来 分 析 ， 便 找到 
了 我 。 我 拿 到 包 之 后 尝试 了 惯用 的 三 板 佐 ， 可 惜 没有 发 现任 何 异常 ， 于 
是 只 能 检查 其 他 方面 的 信息 了 。 

1. 点 击 Wireshark 的 Statistics 菜 单 ， 再 点 击 Conversations， 见 图 1。 
起 UDP.pcap [Wireshark 1.12.2 (v1.12.2-0-g898fa22 from master-1.12)] 
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图 1 
2. 从 TCP 标 签 可 见 传输 的 数据 量 (Bytes) 极 少 ， 见 网 2。 


| Ethernet: 1| Fibre channel| Fop| IPvd: 1 | Ipv6| IPx | JxTA| Ncp| Rsyp| scTp] TCP: 32 | Token Ring| UDP: 5| Us 




















TCP Conversations 
Addre 4 PortA 4 AddressB 4 PotB 4 Packets 4 Bytes  ™ Packets A—B 4 Bytes A—B 4 Packets AB* 日 
Beijing 3387] Shanghai 5040 945 158 992 472 123 006 473 
Beijing 49871] Shanghat 5040 503 76 646 251 55 494 252 
Beijing 39355 Shanghai 5040 455 68 310 227 48 666 228 
Beijing 60163 Shanghat 5040 d441 65 984 220 46 926 221 
Beijing 35123 Shanghat S5040 437 65 253 218 46 155 219 
Beijing 51709 Shanghai S040 436 65 061 218 46 287 218 
图 2 


3. 再 看 UDP 标签 ， 发 现 传输 的 数据 量 〈Bytes) 明显 大 得 多 ， 见 图 
3。 


Ethernet:1 | Fibre Channel| FDD]| IPwvd: 1 | IPve | IPX| IXTA | NCEP| RSYP | SCTP | TCP: 52| Token Ring UDP: 5 | usBj| 











UDP Conversations 
Address A 4 PortA 4 Address B 4 PortB 4 Packets 4 Bytes 4 Packets A—B 4 Bytes A=B 4 Packets A—B4 E 





shanghai 5204 Beljing 5204 473 434 41 623 226 415984 3781149 537 450 

Beijing 5203 shanghal 5202 10 533 695 178 5225 344 850 5 308 

shanghai 5203 Beijing 5202 10 531 695 046 5 307 350 262 5224 

shanghal 5040 Beljing 5040 B45 113210 425 56 946 420 
图 3 


以 上 的 初步 分 析 表 明 数 据 是 通过 UDP 传输 的 ， 而 根据 UDP 在 广域网 
中 一 贯 的 不 靠 谱 表现 〈 并 不 是 说 UDP 这 个 协议 本 身 不 靠 谱 ， 而 是 很 多 基 
于 UDP 的 应 用 程序 没有 做 好 性 能 优化 ) ， 我 认为 这 一 点 需要 独 重 研究 。 
于 是 我 又 粗略 看 了 一 下 Wireshark 的 主 窗口 ， 条 然 发 现 很 多 图 4 这 样 的 报 
错 。 
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No., 
404394 
404395 
404396 
404397 
404578 
404802 
543888 
543889 
543890 
543891 
543892 
543893 
543948 
549061 
549062 
549063 





Time 


317. 
117. 
117. 
117. 
117; 
118. 
200. 
200. 
200. 
200. 
200. 
200. 
201. 
204. 
204. 
204. 


738399 
738399 
738399 
738399 
994370 
762281 
416848 
416848 
416848 
416848 
416848 
416848 
440730 
896331 
896331 
896331 


Source 

Beijing 
Beijing 
Beijing 
Beijing 
Beijing 
Beijing 
Beijing 
Beijing 
Beijing 
Beijing 
Beijing 
Beijing 
Beijing 
Beijing 
Beijing 
Beijing 


Destination 

shanghai 
shanghai 
shanghai 
shanghai 
shanghai 
shanghai 
shanghai 
shanghai 
shanghai 
shanghai 
shanghai 
shanghai 
shanghai 
shanghai 
shanghai 
shanghai 
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ICMP 


Time-to-1ive 
Time-to-1ive 
Time-to-1ive 
Time-to-1ive 
Time-to-]ive 
Time-to-]ive 
Time-to-1ive 
Time-to-1ive 
Time-to-1ive 
Time-to-1ive 
Time-to-1ive 
Time-to-1ive 
Time-to-1ive 
Time-to-l1ive 
Time-to-1ive 
Time-to-1ive 


图 4 


exceeded 
exceeded 
exceeded 
exceeded 
exceeded 
exceeded 
exceeded 
exceeded 
exceeded 
exceeded 
exceeded 
exceeded 
exceeded 
exceeded 
exceeded 
exceeded 


(Fragment 
(Fragment 
(Fragment 
(Fragment 
(Fragment 
(Fragment 
(Fragment 
(Fragment 
(Fragment 
(Fragment 
(Fragment 
(Fragment 
(Fragment 
(Fragment 
(Fragment 
(Fragment 


reassembly 
reassembly 
reassembly 
reassembly 
reassembly 
reassembly 
reassembly 
reassembly 
reassembly 
reassembly 
reassembly 
reassembly 
reassembly 
reassembly 
reassembly 
reassembly 


这 个 报错 很 常见 ， 在 1981 年 公布 的 RFC 792 就 有 介绍 了 : 


If a host reassembling a fragmented datagram cannot complete the 


time 
time 
time 
time 
time 
time 
time 
time 
time 
time 
time 
time 
time 
time 
time 
time 


exceeded) 
exceeded) 
exceeded) 
exceeded) 
exceeded) 
exceeded) 
exceeded) 
exceeded) 
exceeded) 
exceeded) 
exceeded) 
exceeded) 
exceeded) 
exceeded) 
exceeded) 
exceeded) 


reassembly due to missing fragments within its time limit, it discards the 
datagram，and it may send a time exceeded message.( 当 接收 方 因为 分 片 
丢失 而 无 法 按时 完成 数据 包 的 重组 时 ， 它 可 以 放弃 并 回复 一 个 超时 消 


县 O ) 





也 就 是 说 ， 从 上 海 发 往 北 京 的 UDP 数 据 包 被 分 片 传 输 了 。 但 由 于 有 
些 分 片 在 路 上 丢失 ， 导 致 北京 一 方 无 法 完成 重组 ， 所 以 就 出 现 了 图 4 中 
的 报错 ， 过 程 如 图 5 所 示 。 


一 个 UDP 数据 包 被 切 成 6 个 分 片 





CE = 
ee X。 第 6 个 分 片 丢 失 北京 方 无 法 组 装 这 些 
分 片 , 所 以 不 响应 
上 海 方 等 不 到 响应 ， 
所 以 从 头 再 传 一 次 
北京 方 的 响应 
图 5 


从 中 可 见 一 个 分 片 的 丢失 ， 会 导致 所 有 分 片 都 被 重 传 一 过， 效率 极 
低 。 这 个 例子 说 明了 UDP 不 能 把 大 块 数据 先 进行 分 段 ， 所 以 很 容易 被 网 
络 层 分 片 ， 也 说 明了 UDP 是 不 可 靠 的 ， 它 缺乏 一 个 机 制 来 确保 数据 被 安 
全 送 达 ， 所 以 只 能 由 应 用 层 来 负责 重 传 。 

找到 了 根本 原因 ， 解 决 起 来 就 好 办 了 。 在 研发 人 员 能 够 优化 UDP 传 
输 之 前 (技术 上 也 是 可 以 做 到 的 ) ， 我 建议 把 传输 层 换 成 TCP， 这 样 理 
论 上 能 大 幅度 提高 性 能 。 理 由 如 下 。 

TCP 有 拥 春 控制 机 制 ， 能 够 降低 网 络 拥 塞 时 丢 包 的 概率 。 这 一 点 细 
六 起 来 太 复 杂 ， 有 兴趣 的 读者 可 参考 我 的 上 一 本 书 的 70 一 79 页 ， 本 文 束 
不 更 述 了 。 

即便 在 丢 包 概率 一 样 的 情况 下 TCP 也 有 优势 ，TCP 的 分 段 机 制 可 以 
把 数据 拆 小 后 封装 在 多 个 包 里 ， 避 免 了 被 网 络 层 分 片 。 重 传 TCP 包 的 效 
率 可 比重 传 分 片 高 多 了 。 比 如 同样 大 小 的 数据 块 分 成 6 个 TCP 包 传输 ， 
同样 只 丢失 了 最 后 一 个 ， 重 传 过 程 如 图 6 所 示 。 











同一 块 数 据 被 分 成 6 个 TCP 包 发 送 





RS * XK。 第 6 个 TcP 包 丢失 





Ack 前 5 个 TcP 包 


上 海 方 等 不 到 第 6 个 包 的 Ack， 
所 以 决定 重 传 它 








北京 方 的 响应 
图 6 


可 见 TCP 只 需要 重 传 丢失 的 那 一 个 包 ， 而 不 是 所 有 包 ， 所 以 效率 比 
重 传 分 片 高 多 了 。 在 传输 过 程 中 应 用 层 也 不 用 负责 重 传 事宜 ， 因 为 TCP 
是 可 靠 的， 能 确保 数据 被 安全 送 达 。 本 文 的 例子 中 只 用 了 6 个 包 ， 所 以 
对 比 还 不 够 明显 。 假 如 一 块 数据 要 切 成 50 个 包 来 传 ， 那 TCP 的 优势 就 更 
能 体现 出 来 了 。 

项 目 组 按照 我 的 建议 改 成 TCP 之 后 ， 性 能 条 然 承 上 去 了 。 因 此 这 个 
问题 本 质 上 就 这 么 简单 ， 每 一 个 过 得 了 笔试 鸭 人 本 应 该 都 会 的 。 从 课本 
知识 到 实际 应 用 之 间 ， 只 差 一 个 Wireshark 来 率 线 搭桥 。 

当然 了 ， 千 万 不 要 因为 这 个 案例 就 否定 UDP 的 价值 ， 还 记得 我 上 本 
书 提 到 DNS 碍 询 的 例子 吗 ? UDP 在 那 种 场合 就 是 领先 的 。 即 使 在 本 文 的 
场景 中 ， 只 要 研发 团队 给 力 ， 用 UDP 也 可 以 实现 很 好 的 性 能 。 争 论 TCP 
和 UDP 哪 个 更 好 ， 束 像 百 上 度 贴 吧 每 天 在 吵 独子 和 老虎 谁 更 历 害 一 样 无 
聊 。 它 们 俩 都 是 其 领域 之 王 ， 只 不 过 一 个 适合 在 草原 ， 男 一 个 适合 在 森 
林 而 已 。 


个 关于 分 片 的 问题 


上 篇 文章 《一 个 你 本 该 能 解决 的 问题 》 被 一 些 技 术 圈 的 朋友 转载 
后 ， 收 到 了 不 少 网 友 提 问 。 我 从 中 挑 了 几 个 最 有 代表 性 的 ， 在 本 文 一 并 
回答 了 ， 和 希望 也 是 你 感 兴趣 的 。 

问题 1: 为 什么 要 分 片 ? 

20 世 纪 60 年 代 以 前 ， 数 据 通 信和 是 依靠 电路 交换 技术 的 ， 根 本 没有 分 
片 一 说 ， 比 如 传统 电话 。 由 于 电路 交换 的 双方 要 独占 链 路 ， 所 以 利用 率 
很 低 ， 直 到 Paul Baran 和 Donald Davies 发 明了 分 组 交换 的 概念 ， 把 数据 
分 割 成 小 包 后 才 实 现 了 链 路 共享 。 既 然 要 分 割 ， 就 得 先 确 定 一 个 包 的 大 
小 ， 有 趣 的 是 当时 这 两 位 独立 发 明 人 都 在 实验 室 中 选择 了 128 字 节 作 为 
一 个 传输 单位 。 不 过 到 了 20 世 纪 80 年 代 的 以 太 网 中 ， 就 发 展 到 以 1500 字 
节 作 为 最 大 传输 单位 了 ， 即 MTU (Maximum Transmission Unit) 为 
1500。 刨 去 20 字 节 的 头 部 ， 一 个 IP 包 最 多 可 以 携带 1500-20=1480 字 节 的 
数据 。 当 要 传输 的 数据 块 超过 1480 字 节 时 ， 网 络 层 就 不 得 不 把 它 分 片 ， 
封装 成 多 个 网 络 包 。 

问题 2: 发 送 方 是 怎样 确定 分 片 大 小 的 ? 

一 般 来 说 ， 发 送 方 是 依据 自身 的 MTU 来 决定 分 片 大 小 的 。 图 1 演示 
了 一 块 数据 被 MTU 为 1500 的 发 送 方 分 割 成 了 23 个 分 所 的 样子 。 我 们 可 
以 从 “off=0”、“off=1480”、“off=2960” 等 偏 移 量 计算 出 这 些 分 片 所 携带 
的 数据 量 都 为 1480 字 节 ， 和 问题 1 中 的 分 析 一 致 。 




















No. Time Source Destination Protocol Info 

7 0.003174 Client server IPVv4 Fragmented IP protocol (proto=UDP 17，off=0，ID=008c) [Reassembled in #29] 

8 0.003182 Client Server IPV4 Fragmented IP protocol (proto=UDP 17, off=1480, ID=008c) [Reassembled in #29] 
9 0.003186 Client Server IPV4 Fragmented IP protocol (proto=UDP 17，off=2960，ID=008c) [Reassembled in #29] 
10 0.003189 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=4440, ID=008c) [Reassembled in #29] 
11 0.003191 Client Server IPV4 Fragmented IP protocol (proto=UDP 17，off=5920，ID=008c) [Reassembled in #29] 
12 0.003194 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=7400, ID=008c) [Reassembled in #29] 
13 0.003197 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=8880, ID=008c) [Reassembled in #29] 
14 0.003201 Client Server IPV4 Fragmented IP protocol (proto=UDP 17, off=10360, ID=008c) [Reassembled in #29] 
15 0.003203 Client server IPV4 Fragmented IP protocol (proto=UDP 17, off=11840, ID=008c) [Reassembled in #29] 
16 0.003206 Client server IPVv4 Fragmented IP protocol (proto=UDP 17, off=13320, ID=008c) [Reassembled in #29] 
17 0.003208 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=14800, ID=008c) [Reassembled in #29] 
18 0.003211 Client Server IPV4 Fragmented IP protocol (proto=UDP 17，off=16280，ID=008c) [Reassembled in #29] 
19 0.003213 Client Server IPV4 Fragmented IP protocol (proto=UDP 17, off=17760, ID=008cC) [Reassembled in #29] 
20 0.003216 Client Sserver IPv4 Fragmented IP protocol (proto=UDP 17, off=19240, ID=008c) [Reassembled in #29] 
21 0.003219 Client Server IPV4 Fragmented IP protocol (proto=UDP 17，off=20720，ID=008c) [Reassembled in #29] 
22 0.003222 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=22200, ID=008c) [Reassembled in #29] 
23 0.003224 Client Server IPV4 Fragmented IP protocol (proto=UDP 17, off=23680, ID=008c) [Reassembled in #29] 
24 0.003227 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=25160, ID=008c) [Reassembled in #29] 
25 0.003230 Client Server IPV4 Fragmented IP protocol (proto=UDP 17, off=26640, ID=008c) [Reassembled in #29] 
26 0.003233 Client server IPv4 Fragmented IP protocol (proto=UDP 17, off=28120, ID=008c) [Reassembled in #29] 
27 0.003236 Client Server IPV4 Fragmented IP protocol (proto=UDP 17, off=29600, ID=008c) [Reassembled in #29] 
28 0.003238 Client Sserver IPV4 Fragmented IP protocol (proto=UDP 17, off=31080, ID=008c) [Reassembled in #29] 
29 0.003240 Client Server NFS V3 WRITE Call (Reply In 142), FH: Ox2823al91 offset: 0 Len: 32768 UNSTABLE 


图 1 

不 过 你 如 采 经 弟 分 析 各 种 环境 中 的 包 ， 会 发 现 有 些 分 户 并 不 是 携 市 
1480 字 节 ， 而 是 更 大 或 者 更 小 。 这 是 因为 有 些 网 络 是 Jumbo Frame《〈 巨 
帧 ) 或 PPPOE 之 类 的 ， 它 们 的 MTU 并 不 是 1500。 于 是 问题 来 了 ，MTU 
不 一 致 的 两 个 网 络 之 间 要 通信 怎么 办 ? 比如 局 用 巨 帧 之 后 的 MTU 是 
9000 字 市 ， 那 从 及 送 方 出 来 的 包 就 有 9000 字 市 ， 万 一 经 过 一 个 MTU 只 
有 1500 字 市 的 网 络 设备 ， 还 是 可 能 被 重 新 分 片 甚至 丢弃 。 这 种 情况 下 发 
送 方 要 怎样 决定 分 片 大 小 ， 才 能 避免 因为 MTU 不 一 致 而 出 问题 呢 ? 比 
较 理 想 的 办 法 是 先 通 过 Path MTU Discovery 协 议 来 探测 路 径 上 的 最 小 
MTU， 从 而 调 贡 分手 的 大 小 。 可 惜 该 协议 是 依靠 ICMP 来 探测 的 ， 会 被 
很 多 网 络 设备 禁用 ， 所 以 不 太 可 靠 。 总 而 言 之 ， 目 前 发 送 方 没有 一 个 很 
好 的 机 制 来 确定 最 佳 分 片 大 小 ， 所 以 实施 和 运 维 人 员 配 置 MTU 时 必须 
慎之 又 慎 ， 尽 量 使 网 络 中 每 个 设备 的 MTU 保 持 一 致 。 在 以 后 的 文章 中 
我 会 分 享 一 些 由 于 MTU 配 置 出 错 而 导致 的 问题 。 

问题 3: 接收 方 又 是 靠 什么 重组 分 所 的 ? 

假如 分 请 都 到 达 接 收 方 了 ， 要 如 何 重 组 它们 呢 ? 从 图 1 可 见 每 个 分 
厂 痢 包含 了 “off=xxxx，ID=008c” 的 信息 ， 接 收 方 就 是 依据 这 两 个 值 ， 把 
ID 相同 的 分 所 按照 off 值 〈 偶 移 量 ) 进行 重组 的 。 原 理 非 常 简单 ， 唯 一 
的 问题 是 接收 方 如 何 判 断 最 后 一 个 分 片 已 经 到 达 ， 应 该 开始 重组 了 。 请 























看 图 2 所 示 的 最 后 一 个 分 片 ， 也 即 第 29 写 包 ， 它 包含 了 一 个 “More 
fragments=0” 的 Flag， 表 示 它 是 最 后 一 个 分 片 ， 因 此 接收 方 可 以 开始 重 
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0.003230 Client Sserver IPV4 Fragmented IP protocol (proto=UDP 17，off=26640，ID=008c) 

26 0.003233 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=28120, ID=008cC) 
0.003236 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=29600, ID=008cC) 
0.003238 Client Server IPV4 Fragmented IP protocol (proto=UDP 17，off=31080，ID=008c) 

29 0.003240 Client Server NFS V3 WRITE Call (Reply In 142), FH: Ox2823al91 offset: 0 Len 


| 男 Frame 29: 402 bytes on wire (3216 bits)，402 bytes captured (3216 bits) 
| 田 Ethernet II, Src: Intel_d4:4d:e2 (00:04:23:d4:4d:e2), Dst: Clariion_3f:0d:07 (00:60:16:3f:0d:07) 


日 Internet Protocol Version 4, src: Client (10.32.106.159), Dst: Server (10.32.106.72) 
Version: 4 


Header Length: 20 bytes 
田 Differentiated services Field: Ox00 (DsCP Ox00: Default; ECN: Ox00: Not-ECT (Not ECN-Capable Tr 
Total Length: 388 
Identification: 0x008c (140) 
日 Flags: Ox00 
i Reserved bit: Not set 
Don't fragment: Not set 


Ee 
nnn 





而 其 他 的 分 片 ， 比 如 图 3 的 28 号 包 却 包含 了 一 个 “More 
fragments=1 的 Flag， 因 此 接收 方 知道 后 续 还 有 更 多 分 片 ， 所 以 先 缓存 
着 不 重组 。 有 一 个 网 络 攻 击 方 式 就 是 持续 发 送 “More ”fragments” 为 1 的 
包 ， 导 致 接收 方 一 直 绥 存 分 片 ， 从 而 耗 尽 内 存 。 


No. Time Source Destination Protocol Info 
P39 UV» UUJICLE' IlCiik JE Ver Fv Fi GJEIIEEU ZF HI UCUCUS VPi UCU—UUrF 17 UIT 一 JIUU， iU—UVUUOC) 
25 0.003230 Client Sserver IPv4 Fragmented IP protocol (proto=UDP 17, off=26640, ID=008cC) 


26 0.003233 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=28120, ID=008c) 
27 0.003236 Client Server IPV4 Fragmented IP protocol (proto=UDP 17，off=29600，ID=008c) 
28 0.003238 Client Server IPv4 Fragmented IP protocol (proto=UDP 17, off=31080, ID=008cC) 


Frame 28: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) 
由 Ethernet II, Src: Intel_d4:4d:e2 (00:04:23:d4:4d:e2), Dst: Clariion_3f:0d:07 (00:60:16:3f:0d:07) 


日 Internet Protocol Version 4, src: Client (10.32.106.159), Dst: Server (10.32.106.72) 
Version: 4 


Header Length: 20 bytes 
Differentiated services Field: Ox00 (DsCP Ox00: Default; ECN: Ox00: Not-ECT (Not ECN-Capable T 
Total Length: 1500 
Identification: 0x008c (140) 
Flags: Ox01 (More Fragments) 
i Reserved bit: Not set 
Don't fragment: Not set 


田 


回 


eae 








图 3 
问题 4: TCP 是 如 何 避 人 免 被 发 送 方 分 片 的 ? 
TCP 可 以 避免 被 发 送 方 分 片 ， 是 因为 它 主 动 把 数据 分 成 小 段 再 交 给 
网 络 层 。 最 大 的 分 段 大 小 称 为 MSS (Maximum Segment Size) ， 它 相当 


于 把 MTU 人 刨 去 耻 头 和 TCP 头 之 后 的 大 小 ， 所 以 一 个 MSS 恰 好 能 装 进 一 个 
MTU 中 。 
MTU 


MSS 
图 4 
图 4 演示 了 MSS 和 MTU 的 关系 。 有 的 时 候 TCP 头 不 只 20 字 市 ， 所 以 
会 侵占 一 些 MSS 的 空间 ， 比 如 图 5 的 例子 中 就 占用 12 字 节 作 为 TCP 
Options， 那 传输 层 真 正 用 来 承载 数据 的 焉 剩 下 1500-20-20-12=1448 字 节 
了 。 这 些 字 节 数 都 能 在 Wireshark 中 看 到 。 这 就 是 为 什么 我 向 网 络 教师 们 
大 力 推荐 Wireshark， 演 示 时 真是 一 目 了 然 。 


四 Frame 58: E14] bytes on wire (12112 bits), 1514 bytes captured (12112 bits) 
四 Ethernet II, Src: Intel_d4:4d:e2 (00:04:23:d4:4d:e2), Dst: Clariion_2b:5d:b2 (00:60:16:2b:5d:b2) 
日 Internet Protocol Version 4, src: Client (10.32.106.159), Dst: Server (10.32.106.62) 
Version: 4 
Header Length: 20 bytes 
田 Differentiated services Field: Ox00 (DsCP Ox00: Default; ECN: Ox00: Not-ECT (Not ECN-Capable Transport)) 
Total Length: 
Identification: Ox8led (33261) 
田 Flags: Ox02 (Don't Fragment) 
Fragment offset: 0 
Time to live: 64 
Protocol: TCP (6) 
由 Header checksum: 0xcall [validation disabled] 
source: Client (10. 32.106.159) 
Destination: Server (10. 32.106. 62) 
[source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
Transmission Control Protocol, Src Port: 706 (706), Dst Port: 2049 (2049), seq: 9133, Ack: 1049, Len: |1448| 
source Port: 706 (706) 
Destination Port: 2049 (2049) 
[stream index: 2] 
[TCP Segment Len: 1448] 











回 


sequence number: 9133 (relative sequence number) 
[Next sequence number: 10581 (relative sequence number)] 
Acknowledgment number: 1049 (relative ack number) 


Header Length: 32 bytes 

. 0000 0001 0000 = Flags: Ox010 (ACK) 
Window size value: 694 
[Calculated window size: 22208] 
[window size scaling factor: 32] 
Checksum: Oxf320 [validation disabled] 
Urgent pointer: 0 


田 Options: G2 bytes]， No-Operation (NOP), No-Operation (NOP), Timestamps 
图 5 
UDP 则 没有 MSS 的 概念 ， 一 股 脑 交 给 网 络 屋 ， 所 以 可 能 被 分 片 。 分 
片 和 重组 都 会 影响 性 能 ， 所 以 UDP 在 这 一 点 上 比 TCP 落 后 一 些 。 


田 





田 





问题 5: 那 TCP 又 是 怎样 适 配 接收 方 的 MTU 的 ? 

问题 4 只 分 析 了 为 什么 TCP 包 不 会 被 发 送 方 的 网 络 层 分 片 。 那 万 一 
接收 方 的 MTU 比 发 送 方 的 小 怎么 办 ?比如 发 送 方 启用 了 巨 帧 〈Jumbo 
Frame) ， 把 MTU 提 高 到 9000 字 节 ， 但 接收 方 还 停留 在 1500 字 节 的 情 
况 。 这 个 问题 其 实在 我 的 上 一 本 书 中 提 到 过 ，TCP 建 立 连 接 时 必须 先进 
行 三 次 握手 (如 图 6 所 示 〉 ， 在 前 两 个 握手 包 中 双方 互相 声明 了 自己 的 
MSS， 客 户 端 声明 了 MSS=8960， 服 务 器 声明 了 MSS=1460。 三 次 握手 之 
后 ， 客 户 病 知道 自己 的 MTU 比 服务 器 的 大 ， 如 果 发 一 个 9000 字 节 的 包 
过 去 很 可 能 在 路 上 就 被 分 片 或 丢弃 。 于 是 在 这 个 连接 中 ， 客 户 端 会 很 识 
相 地 把 自己 的 MSS 也 降 到 1460 字 节 ， 从 而 适 配 了 接收 方 的 MTU。 











3 ooo000 lien Server er Penis [ew seqro wnt? or tonal scree 
3 0.003906 client server TCcp 33763-111 [ACK] Seq=1 Ack=1 Win=17920 Len=0 Tsval=27300530， 
图 6 

TCP 在 避免 分 片 这 一 点 上 已 经 做 得 足够 用 心 ， 发 送 方 和 接收 方 都 考 
虚 到 了 。 然 而 网 络 上 的 隐患 防不胜防 ， 假 如 路 径 上 有 个 交换 机 的 MTU 
比 发 送 方 和 接收 方 的 都 小 ， 那 还 是 会 出 问题 。 

问题 6， 为 什么 UDP 比 TCP 更 适合 语音 通话 ? 

如 果 把 UDP 和 TCP 想 象 成 两 位 搬运 工 ， 前 者 的 风格 就 是 盲目 苦 干 ， 
搬运 过 程 中 丢 了 东西 也 不 管 ， 而 后 者 却 是 小 心 囊 囊 ， 丢 了 多 小 的 东西 都 
要 回去 捡 。 假 如 某 个 应 用 环境 允许 忽视 质量 ， 只 追求 速度 ， 那 UDP 就 是 
一 个 更 好 的 选择 。 语 音 传 输 正 符合 这 种 情况 ， 因 为 它 最 在 乎 的 不 是 音 
质 ， 而 是 延迟 。 

采用 UDP 传输 时 ， 如 果 有 些 包 丢失 ， 应 用 层 可 以 选择 忽略 并 继续 传 
答 其 他 包 。 由 于 一 个 发 音 会 被 采样 到 很 多 个 包 中 ， 所 以 丢掉 其 中 一 些 包 
只 是 影响 到 了 音质 ， 却 能 保障 流畅 性 。 

而 采用 TCP 传 输 时 ， 出 现 丢 包 就 一 定 要 重 传 ， 重 传 就 会 带 来 延迟 。 
这 是 TCP 与 生 俱 来 的 特点 ， 即 使 应 用 层 想 忽略 丢 包 都 没 办 法 。 前 文 说 过 























TCP 的 优点 是 可 徘 ， 有 丢 包 重 传 机 制 ， 这 个 优点 在 语音 传 输 时 束 变 成 了 
缺点 。 通 话 延迟 的 后 果 很 严重 ， 比 如 你 在 语音 聊天 时 对 女神 说 , “这 是 
我 的 头像 ， 牛 吧 ? ”如 果 在 “ 头 ” 和 " 像 ” 之 间 恰 好 多 出 一 段 延迟 ， 对 方 听 
上 去 就 可 能 变 成 * 这 是 我 的 头 ， 像 一 牛 吧 ? ”然后 给 你 回 一 句 , “很 像 ! ” 














MTU 导 致 的 莫 届 


MTU 带 来 的 问题 实在 太 多 了 ， 但 凡 做 过 运 维 、 实 施 或 者 技术 支持 
的 工程 师 ， 或 多 或 少 都 会 遇 到 。 一 个 典型 的 MTU 问 题 发 生 在 类 似 图 1 的 
环境 中 ， 即 两 个 子 网 的 MTU 大 小 不 一 样 。 







MTU=9000 MTU=1500 





客户 端 路 由 器 服务 器 
图 1 


当 客 户 问 发 给 服务 器 的 巨 帧 经 过 路 由 需 时 ， 或 者 被 丢 包 ， 或 者 和 ”分 





片 。 这 取决 于 该 巨 帧 是 否 在 网 络 层 携带 了 DF (Dom’t fragment) 标志 。 
如 果 帝 了 就 补 丢 弃 ， 如 有 果 没 禹 就 被 分 片 。 从 Wireshark 上 很 容易 看 到 DF 
标志 ， 如 图 2 中 的 方 框 内 所 示 。 分 片 的 情况 往往 被 忽略 ， 因 为 它 只 影响 
一 点 点 性 能 ， 大 多 数 时 候 甚 至 察觉 不 出 。 丢 包 的 情况 就 无 法 忽略 了 ， 
为 丢 包 之 后 再 章 传 多 少 裔 都 没 用 ， 会 一 直 和 于， 整个 传输 就 像 挥 进 了 黑 

润 ， 所 以 往往 会 导致 严重 的 后 采 。 

No. Time Source Destination Protocol Info 


1 0.000000000 Cclient server ICMP Echo (ping) request id=0x0001 ， 
| Wh 


四 Frame 1: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) . 
由 Ethernet II, Src: Universa_50:a9:f6 (44:39:c4:50:a9:f6), Dst: Cisco_e3:a6:8!( 
日 Internet Protocol version 4, src: 10.32.200.23 (10.32.200.23), Dst: 10.32.1!( 
Version: 4 
Header Length: 20 bytes 
加 Differentiated services Field: Ox00 (DsCP Ox00: Default; ECN: Ox00: Not-E( 
Total Length: 1500 
Identification: Ox1314 (4884) 
日 Flags: Ox02 (Don't Fragment) 
0... .... = Reserved bit: Not set 














More Tragments: Not set 


图 2 
我 有 个 实验 环境 恰好 就 是 图 1 这 样 的 ， 可 以 来 做 个 实验 加 深 理 解 。 
我 从 客户 疹 给 服务 器 发 送 了 两 个 ping 请 求 ， 第 一 个 携带 1472 字 节 ， 第 二 
个 携 市 1473 字 节 ， 并 都 用 了 “-f” 参 数 设置 了 DF 标志 。 命 令 及 结果 请 看 图 
3， 第 一 个 ping 成 功 ， 第 二 个 则 失败 了 。 
本 C\Windows\system32\cmd.exe CE 
C:\Users\linpi>ping 196.32.166.162 -1 1472 -f -n 1 














Pinging 16.32.166.162 with 1472 bytes of data: 
Reply from 19.32.1696.162: bytes=1472 time=1ms TTL=251 


Ping statistics for 19.32.196.162: 

Packets: Sent = 1, Received = 1, Lost = 8 (6% loss), 
Approximate round trip times in milli-seconds: 

Minimum = ims, Maximum = ims, Average = 1ms 


C:\Users\linpi>ping 18.32.186.182 -1 1473 -f -n 1 


MPinging 16.32.166.162 with 1473 bytes of data: 
Reply from 18.32.288.1: Packet needs to be fragmented but DF set. 








图 3 

由 于 ICMP 头 为 8 字 节 ， 卫 头 为 20 字 节 ， 所 以 第 一 个 ping 请 求 在 网 络 
层 的 长 度 为 1472+8+20=1500 字 节 ， 第 二 个 ping 请 求 则 为 1473+8+20=1501 
字 节 。 我 的 路 由 器 MTU 是 1500 字 节 ， 不 难 理解 第 一 个 ping 请 求 的 长 度 没 
有 超过 MTU， 所 以 可 以 传输 成 功 ; 而 第 二 个 ping 请 求 的 长 度 超过 了 路 由 
器 出 口 的 MTU， 又 不 允许 被 切 分 ， 所 以 不 能 传输 成 功 。 在 图 3 底部 可 以 
看 到 路 由 器 提示 了 “Packet needs to be fragmented but DF set”。 

这 个 过 程 的 网 络 包 可 以 从 图 4 中 看 到 ， 请 注意 最 后 一 个 包 是 路 由 器 
回复 的 “Fragmentation needed”， 而 不 是 服务 器 回复 的 。 假 如 ping 的 时 候 
没有 用 “-f” 设 置 DF 标志 ， 那 么 1473 字 节 也 是 能 ping 成 功 的 ， 只 是 在 路 上 
会 被 切 分 成 两 个 包 。 








Filter: icmp [= | Expression.. Clear Apply Save 


No, Time Source Destination Protocol Info 

0.000000000 Client Server ICMP Echo (ping) request id=0x0001, seq=44/11264,， 

0.001248000 server Client ICMP Echo (ping) reply id=0x0001，seq=44/11264， 

5.311831000 Client Server ICMP Echo (ping) request id=0x0001, seq=45/11520, 

5.313062000 Router Client ICMP Destination unreachable (Fragmentation needed) 
人 


田 Frame 4: 1515 bytes on wire (12120 bits), 1515 bytes captured (12120 bits) on interface 0 
由 Ethernet II，Src: Universa_50:a9:f6 (44:39:c4:50:a9:f6), Dst: Cisco_e3:a6:80 (ec:30:91:e3: 
日 Internet Protocol Version 4, Src: Client {10.32.200.23), Dst: Server (10. 32.106.102) 
Version: 4 
Header Length: 20 bytes 
四 Differentiated services Field: Ox00 (DsCP Ox00: Default; ECN: Ox00: Not-ECT (Not ECN-Cap 
Identification: Ox132b (4907) 
日 Flags: Ox02 (Don't Fragment) 
0... .... = Reserved bit: Not set 








Mw 














.0. .... = More ee Not set 
Fragment offset: 0 
Time to live: 128 
Protocol: ICMP (1) 

田 Header checksum: Ox0000 [validation disabled] 
Source: Client (10. 32.200.23) 
Destination: Server {10.32.106.102) 
[Source GeoIP: Unknown] 

[Destination GeoIP: Unknown] 

Type: 8 (Echo (ping) request) 

Code: 0 

Checksum: Oxdf1i9 [correct] 

Identifier (BE): 1 (Ox0001) 

Identifier (LE): 256 (Ox0100) 

sequence number (BE): 45 (0x002d) 

sequence number (LE): 11520 (0x2d00) 


四 [NO response seen] 
四 Data_ (1473 bytes)l 
图 4 


理论 说 起 来 很 简单 ， 实 验 做 出 来 也 不 难 ， 但 在 生产 环境 中 的 症状 就 
没 这 么 明显 了 ， 要 发 现 MTU 问 题 往 往 需要 一 些 想象 力 。 我 收藏 了 不 少 
MTU 相 关 的 案例 ， 在 本 文 挑 出 三 个 最 有 代表 性 的 i 

案例 1 用 户 浏览 茶 些 共 吾 目录 时 客户 端 会 死机 ， 浏 览 其 他 目录 则 不 











磁 到 这 种 症状 ， 疏 但 没有 人 会 想到 是 MTU 导 致 的 ， 所 以 经 过 长 时 
间 徒 劳 无 功 的 排 错 之 后 ， 工 程 师 不 得 不 抓 了 个 包 。 这 个 包 是 在 服务 器 上 
抓 的 《因为 客户 端 死 机 ， 根 本 没 法 抓 》》， 如 图 5 所 示 ， 服 务 器 回复 的 
包 “Seq=193，Len=1460” 在 持续 重 传 ， 但 客户 端 一 直 没 有 确认 ， 似 乎 是 

















发 生 丢 包 了 。 从 图 5 底部 还 可 以 看 到 这 个 包 携 带 的 信息 是 该 目录 的 子 文 
作 列表 : 


Ne. Time Source Destination Protocol Info 
1 0.000000 Client server SMB Trans2 Request, QUERY_PATH_INFO, Query File Basic Info, Path: 
2 0.000165 Server Client SMB Trans2 Response, QUERY_PATH_INFO 
3 0.008587 Client Server SMB Trans2 Request, QUERY_PATH_INFO, Query File standard Info, Path: 
4 0.008677 server Client SMB Trans2 Response, QUERY_PATH_INFO 
5 0.011474 Client server SMB Trans2 Request, FIND_FIRST2, Pattern: \* 
6 0.011986 Server Client TCP [TCP segment of a reassembled PDU] 
7 0.011992 server Client SMB Trans2 Response, FIND_FIRST2, Files: . lost+found .etc Sales TEMP Branch 
8 0.033961 Client server TCP [TCP Dup ACK 5#1] 3476-445 [ACK] Seq=251 Ack=193 Win=64289 Len=0 SLE=3113 
9 1.181895 Server Client TCP [TCP Retransmission] 445-3476 [ACK] Seq=193 Ack=251 Win=65535| Len=1460 
10 4.178112 Sserver Client TCP [TCP Retransmission] 445-~3476 [ACK] Seq=193 Ack=251 Win=65535| Len=1460 
11 10.182512 server Client TCP [TcP Retransmission] 445-3476 [ACK] Seq=193 Ack=251 Win=65535| Len=1460 
12 22.183406 server Client TCP [TCP Retransmission] 445-3476 [ACK] Seq=193 Ack=251 Win=65535| Len=1460 
13 46.185134 Server Client TCP [TCP Retransmission] 445-3476 [ACK] Seq=193 Ack=251 Win=65535| Len=1460 


4 | Ud 


日 FIND_FIRST2 Data 
9 Find File Both Directory Info File: . 
9 Find File Both Directory Info File: lost+found 
习 Find File Both Directory Info File: .etc 
四 Find File Both Directory Info File: sales 
9 Find File Both Directory Info File: TEMP 
习 Find File Both Directory Info File: Branch Checklist 
9 Find File Both Directory Info File: Thumbs. db 
Find File Both Directory Info File: 0ps 
9 Find File Both Directory Info File: PMS 





图 5 

导致 于 包 的 可 能 性 有 很 多 ， 我 为 什么 认定 是 MTU 导 致 的 呢 ?” 推 理 
过 程 如 下 。 

1. 如 果 病 口 被 防火 墙 阻 止 了 也 可 能 丢 包 ， 但 是 会 从 三 次 握手 时 就 
开始 丢 ， 而 不 是 等 到 浏览 目录 的 时 候 。 

2. 如 果 网 络 拥 宅 也 可 能 丢 包 ， 但 一 段 时 间 后 能 恢复 ， 而 不 是 这 样 
持续 地 丢 。 

3. 丢 的 那个 包 携 珊 了 1460 字 节 〈 相 当 于 占 满 了 整个 1500 字 节 的 
MTU) ， 算 是 比较 大 的 。 而 没 被 丢弃 的 2 号 包 和 4 号 包 都 携带 了 很 少 的 
字 节 数 ， 只 丢 大 包 的 症状 说 明 很 可 能 就 是 MITU 导 致 的 。 

4. 我 用 “ping<server_ ip>-] 1472-f? 测 试 ， 果 然 失 败 了 。 逐 渐 减 小 每 
次 ping 的 长 度 ， 到 了 1400 字 节 左 右 才 成 功 ， 这 说 明 网 络 上 有 个 设备 的 
MTU 比 较 小 。 

5. 于 是 把 服务 器 上 网 卡 的 MTU 相 应 改 小 ， 问 题 果然 就 消失 了 。 

6. 之 所 以 浏览 其 他 目录 没有 死机 ， 可 能 是 因为 这 些 目 录 中 的 子 文 
件 〈 夹 ) 比较 少 ， 凌 不 满 一 个 大 包 。 











我 曾经 访问 公司 内 网 时 出 现 问题 ， 在 抓 包 里 也 看 到 类 似 于 图 5 的 症 
状 ， 后 来 也 是 通过 修改 MTU 解 决 的 。 

案例 2 客户 问 的 MTU 为 1500 字 节 ， 服 务 器 端的 MTU 为 9000 字 节 ， 平 
时 连接 正常 。 运 维 人 员 听 说 两 端的 MTU 最 好 一 致 ， 所 以 把 客户 端的 
MTU 提 高 到 9000 字 节 ， 没 想到 连接 反而 出 问题 了 。 

虽然 该 案例 听 上 去 不 太 科学 ， 但 如 果 网 络 路 径 上 有 个 设备 的 MTU 
是 1500 字 节 ， 这 个 问题 就 真 会 发 生 。 原 先 客户 端 和 服务 器 在 三 次 握手 
时 ， 双 方 会 “协商 ”使 用 一 个 1460 字 节 (MTU-TCP 头 -IP 头 ) 的 MSS， 所 
以 可 以 顺利 通过 那个 MTU 为 1500 的 网 络 设备 。 如 果 两 端 都 是 9000 字 节 
了 ， 那 三 次 握手 时 就 会 得 到 8960 字 节 的 MSS， 因 此 通 不 过 那个 网 络 设 
备 。 

案例 3 无 法 完成 Kerberos 身 份 认证 ， 在 客户 端 抓 到 的 包 如 图 6 所 示 。 

由 图 6 可 见 客 户 端 在 持续 地 向 KDC 发 送 TGS-REQ， 但 是 收 不 到 任何 
回复 。 本 来 磁 到 这 种 情况 最 好 在 KDC 上 也 抓 个 包 看 看 的 ， 但 是 KDC 一 
般 不 让 人 登 上 去 。 怎 么 办 了 呢 ? 





No, Time Source Destination Protocol Info 
95 256.218750 Client KDC KRB5 TGS-REQ 
96 261.218750 Client KDC KRB5 TGS-REQ 
97 261.988281 Client KDC KRBS5 TGS-REQ 
98 266.218750 Client KDC KRB5 TGS-REQ 
99 266.988281 Client KDC KRB5 TGS-REQ 


Hh 


User Datagram Protocol, src Port: 62744 (62744), Dst Port: 88 (88) 
3 Kerberos 
3 tgs-req 
pvno: 5 
msg-type: krb-tgs-req (12) 
由 padata: 1 item 
日 req-body 
Padding: 0 
习 kdc-options: 00000000 


十 | 


图 6 
从 这 几 个 网 络 包 里 是 挖 气 不 出 更 多 线索 了 ， 我 们 只 能 推测 哪些 因素 








会 导致 TGS-REQ 得 不 到 回复 。 有 一 个 可 能 是 端口 被 防火 墙 封 掉 ， 但 那 
样 的 话 之 前 的 其 他 Kerberos 包 《比如 AS-REQ) 也 得 不 到 回复 ， 不 可 能 
走 到 TGS-REQ 这 一 步 ， 因 此 防火 墙 可 以 排除 。 还 有 一 个 可 能 就 是 MTU 
导致 的 丢 包 了 ， 假 如 网 络 路 径 上 有 个 交换 机 的 MITU 偏 小， 大 包 无 法 通 
过 就 可 能 出 现 此 症状 。 仅 从 Wireshark 中 我 们 无 法 判断 是 客户 端 发 给 
KDC 时 丢 包 了 ， 还 是 KDC 回 复 客 户 端 时 丢 包 了 ， 只 能 先 试 着 把 客户 病 
的 MTU 改 小 一 点 ， 问 题 果 然 就 消失 了 。 其 实 利 用 “ping-f-1< 字 节 数 >” 试 
探 出 路 径 上 的 最 小 MTU 也 可 以 ， 前 提 是 网 络 中 没有 禁用 ICMP。 





10 思 


有 位 运 维 人 员 跟 我 讲 了 一 件 趣事 : 他 有 个 客户 端 连 不 上 某 人 台 服 务 
器 ， 但 连接 其 他 服务 器 都 没有 问题 ， 那 台 服 务 器 跟 其 他 客户 端的 通信 也 
很 好 ， 唯 独 遇 到 这 个 客户 端 就 不 行 。 这 种 情况 已 经 不 能 用 排除 法 来 定位 
根源 了 ， 就 好 像 它们 天 生 相克 一 样 。 

运 维 团 队 已 经 研究 了 很 多 天 ， 还 是 毫 无 头绪 ， 于 是 就 在 客户 端 抓 了 
个 包 给 我 分 析 。 从 图 1 可 见 ， 这 个 连接 的 确 出 了 问题 。 具 体 分 析 如 下 。 

1. 1 号 包 和 2 号 包 是 MAC 地 址 解析 过 程 。 即 客户 端 通 过 ARP 广 播 ， 

获得 了 服务 器 的 MAC 地 址 00:15:5d (本 文 只 显示 MAC 地 址 的 前 半 部 
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2. 3、4、5 号 包 是 客户 端 向 服务 器 发 起 的 三 次 握手 ， 此 时 看 起 来 并 
没有 问题 。 

ec i 出 发 给 服务 器 的 数据 ， 但 由 于 服务 器 没有 响应 ， 所 
以 在 7 号 包 重 传 了 一 裔 。 到 这 一 步 已 经 显示 出 传输 问题 了 

4. ee ee ACK]， 表 明 它 是 4 号 包 的 重 
传 。 也 就 是 说 ， 从 服务 器 的 角度 看 ，4 号 包 还 没有 送 达 客户 端 ， 意 味 着 
三 次 握手 还 没 真 正 完 成 。 

5. 接 下 来 的 包 仍 然 是 重 传 ， 说 明和 它们 根本 无 法 正常 通信 














No. Time Source Destination Protocol Info 
1 0.000000 00:60:48ff:ff:ff: ARP Who has 192.168.47.250? Te11 192.168.47.200 
2 0.003906 00:15:5d00:60:48: ARP 192.168.47.250 is at 00:15:5d 
3 0.046875 Client Server TCP 51754-389 [SYN] seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1 WS=8 
4 0.046875 Server Client TCP 389-51754 mas ACk=1 Win=8192 Len=0 MSS=1460 WS=256 
5 0.046875 Client Server TCP 51754-389 [ACK] Seq=1 Ack=1 Win=139264 Len=0 TSval=433697 TSecr 
6 0.046875 Client server LDAP bindRequest(1) "<ROOT>"” simple 
7 1.156250 Client server LDAP [TCP Retransmission] bindRequest(1) "<ROOT>" simple 
8 3.058594 Server Client TCP [TCP Spurious Retransmission] 389-51754 [sw segjseq-o ACk=1 
9 3.058594 Client server TCP [TCP Dup ACK 7#1] 51754-389 [ACK] Seq=15 Ack=1 Win=139264 Len=0 
10 4.156250 Client server LDAP [TCP Retransmission] bindRequest(1) "<ROOT>" simple 
11 9.070312 Server Client TCP [TCP Spurious Retransmission] 389-51754 seq=0 Ack=1 





图 1 


我 们 能 从 这 个 现象 中 推理 出 什么 呢 ? 至 少 可 以 知道 3 号 包 能 够 到 达 
服务 器 ， 因 此 才 会 有 4 号 包 的 [SYN，ACK]。 但 是 5 号 包 却 没 能 到 达 服 务 
器 ， 因 此 服务 器 收 不 到 对 4 号 包 的 确认 ， 不 得 不 选择 重 传 。 这 就 很 奇怪 
了 ， 既 然 3 号 包 可 以 到 达 服 务 器 ， 说 明 不 存在 路 由 交换 或 者 防火 墙 方面 
的 障碍 ， 为 什么 5 号 包 就 到 达 不 了 呢 ? 以 我 过 往 的 经 验 是 无 法 凭空 想象 
出 原因 的 ， 只 能 继续 在 Wireshark 中 寻找 线索 ， 逐 个 包 分 析 。 先 看 看 图 2 
中 的 3 号 包 ， 是 从 客户 端 发 到 服务 器 的 MAC 地 址 00:15:5d， 与 ARP 中 看 
到 的 地 址 一 致 。 


No. Time Source Destination Protocol Info 
1 0.000000 00:60:48ff:ff:ff: ARP Who has 192.168.47.250? Tell 192.168.47.200 
2 0.003906 00:15:5d00:60:48: ARP 192.168.47.250 is at [00:15:5d] 
3 0.046875 Client Server TCP 51754-389 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACI 


Wh 


Frame 3: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) 














由 Ethernet II, Src: 00:60:48 Dst:100:15:5d 
由 Internet Protocol Version 4, src: Client (192.168.47.200), Dst: Server (192.168.47.250) 
图 2 


再 看 图 3 中 4 号 包 的 详情 ， 竞 然 是 从 服务 器 的 MAC 地 址 ec:b1:d7 发 出 
来 的 ， 而 不 是 之 前 看 到 的 那个 00:15:5d。 为 什么 会 莫名 其 妙 地 出 现 这 个 
MAC? 它 会 带 来 什么 影响 ? 目前 还 不 得 而 知 。 


No. Time Source Destination Protocol Info 








1 0.000000 00:60:48ff:ff:ff: ARP Who has 192.168.47.250? Tell] 192.168.47.200 

2 0.003906 00:15:5d00:60:48: ARP 192.168.47.250 is at 00:15:5d 

3 0.046875 Client server TCP 51754-389 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SAC 

4 0.046875 Sserver Client TCP 389-+51754 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 Ms 
4 | 
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Frame 4: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) 





9 Ethernet II, Src: Dst: 00:60:48 
由 Internet Protocol Version 4, Src: Server (192.168.47.250), Dst: Client (192.168.47.200) 
图 3 





再 看 图 4 中 的 5 号 包 ， 客 户 端 把 它 发 到 这 个 新 的 MAC 地 址 ec:b1:d7 
了 。 难 道 这 就 是 无 法 送 达 的 原因 吗 ? 我 觉得 非常 有 可 能 。 





No. Time Source Destination Protocol Info 


1 0.000000 00:60:48ff:ff:ff: ARP Who has 192.168.47.250? Tell 192.168.47.200 

2 0.003906 00:15:5d00:60:48: ARP 192.168.47.250 is at 00:15:5d 

3 0.046875 Client server TCP 51754-+389 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SAC 
4 0.046875 Sserver Client TCP 389-51754 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MS 
5 0.046875 Client server TCP 51754-389 [ACK] Seq=1 Ack=1 Win=139264 Len=0 TSval 
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HFrame 5: 66 bytes on wire (528 bits), 66 bytes captured 二 bits) 
由 Ethernet II, Src: 00:60:48 


习 Internet Protocol Version 4, Src: Client (192.168.47. i 让 server (192.168.47.250) 


图 4 

分 析 到 这 里 ， 我 们 可 以 作出 进一步 推理 。 

1. 服务 器 上 的 一 个 IP 对 应 了 两 个 MAC 地 址 ， 其 中 00:15:5d 能 收 
包 ， 但 不 知道 为 什么 没 发 包 ; 而 ec:b1:d7 能 发 包 却 收 不 到 包 。 我 还 是 第 
一 次 看 到 这 样 诡异 的 状况 。 

2. 客户 并 的 表现 也 很 奇怪 。 明 明 能 通过 ARP 获 得 服务 器 的 MAC 地 
址 〈 即 00:15:5d) ， 但 一 看 到 对 方 的 发 来 的 包 里 MAC 有 变化 〈 即 变 成 
ec:b1:d7) ， 就 立即 回复 给 这 个 新 MAC。 一 般 的 主机 都 是 持续 使 用 缓存 
在 ARP 表 里 的 那个 老 MAC 地 址 的 。 

也 就 是 说 ， 这 两 台 设 备 各 自 有 一 个 奇怪 的 特征 ， 单 独 存 在 时 都 不 会 

出 问题 ， 但 是 放 到 一 起 就 不 行 了 。 我 们 只 要 纠正 其 中 一 方 的 行为 ， 问 题 
就 能 解决 了 。 

运 维 人 员 最 后 选择 在 客户 端 启用 ARP 表 ， 果 然 问题 就 消失 了 ， 因 为 
从 此 客户 端 只 发 包 给 00:15:5d。 不 过 我 最 感 兴趣 的 还 是 那 台 服 务 器 的 配 
置 ， 为 什么 一 个 IP 会 对 应 两 个 MAC 呢 ?后 来 终于 拿 到 了 配置 信息 ， 原 来 
服务 器 上 的 多 个 网 卡 被 绑 定 成 一 个 NIC Teaming， 类 型 为 Transmit Load 
Balancing (CTLB) 。TLB 的 特点 就 是 收 包工 作 只 由 一 个 网 卡 负责 ， 发 包 
工作 则 分 摊 给 所 有 网 卡 ， 如 图 5 所 示 。 也 就 是 说 00:15:5d 既 能 收 也 能 
但 ec:b1:d7 只 能 发 不 能 收 ， 所 以 当 客 户 端 把 包 回 给 ec:b1:d7 的 时 候 就 被 丢 
弃 了 。 











像 这 样 隐蔽 的 问题 ， 假 如 没有 Wireshark 真 不 知道 如 何 解决 。 而 有 了 
Wireshark 却 显得 很 简单 ， 即 使 对 配置 信息 一 无 所 知 也 能 迎刃而解 。 如 果 
说 有 什么 工具 能 彻底 改善 工作 体验 ， 我 的 回答 训 无 疑问 是 Wireshark。 
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1998 年 ， 在 波士顿 附近 的 一 座 小 镇 上 ， 几 位 技术 人 员 被 召集 到 了 一 
起 。 他 们 都 是 存储 巨头 EMC 的 工程 师 ， 目 的 是 找到 一 个 方法 来 缓解 当时 
网 络 带宽 所 形成 的 性 能 瓶颈 。 

今天 的 年 轻 人 已 经 难以 想象 20 世 纪 90 年 代 的 网 络 带宽 是 什么 样子 
的 。 初 期 连 数据 中 心里 的 服务 器 都 只 有 十 兆 ， 后 来 才 增加 到 百 兆 。 而 现 
在 一 台 廉 价 电 脑 都 已 经 配 千 兆 卡 了 ， 这 样 对 比 一 下 你 就 能 理解 当时 的 网 
络 有 多 落后 。 低 带宽 对 个 人 电脑 还 不 算 大 问题 ， 但 对 企业 级 服务 器 就 是 
严重 的 瓶 须 了 ， 比 如 在 网 络 存 储 上 读 写 大 量 数据 的 时 候 《〈 拓 扑 见 图 
1) 。 想 象 一 下 ， 假 如 你 是 当时 上 元 斯 动画 工作 室 的 员工 ， 每 天 要 访问 
动 轰 1GB 以 上 的 视频 文件 ， 性 能 体验 该 有 多 糟糕 。 有 什么 办 法 可 以 解决 


这 个 问题 呢 ? 
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以 太 网 交换 机 


服务 器 


以 我 的 创新 能 力 和 知识 视野 ， 如 果 参 与 这 个 项 目 估 计 只 能 做 做 流 
控 ， 尽 量 使 传输 性 能 接近 理论 最 大 值 。 而 这 个 项 目 组 显然 更 有 创意 ， 他 
们 想到 了 当时 带宽 已 经 达到 2 Gbit/s 的 FC (Fibre Channel) 。 成 功 的 话 可 
以 从 百 兆 提升 到 2 Gbiys， 增 幅 的 确 非 常 大 。 

讲 到 这 里 就 得 补充 一 下 网 络 存储 的 架构 。 如 图 2 所 示 .外 ， 当 时 的 网 
络 存 储 是 用 多 个 硬盘 组 成 LUN 即 一 层 虚拟 的 存储 设备 ) ， 然 后 再 在 
LUN 上 创建 文件 系统 ， 供 以 太 网 上 的 NFS 或 CIFS 客 户 端 访问 。 





Ethernet 





可 惜 FC 有 别 于 以 太 网 ， 它 支持 访问 LUN， 但 不 支持 访问 文件 系 
统 。 也 就 是 将， 我 们 不 能 简单 地 把 图 2 的 以 太 网 连接 蔡 换 成 FC。 如 果 把 
客户 端 和 LUN 之 间 用 FC 连接 起 来 ， 变 成 图 3 的 样子 ， 那 么 市 冤 的 确 能 提 
高 好 多 倍 。 然 而 新 的 问题 又 来 了 ， 客 户 端 是 不 知道 文件 存放 在 LUN 上 的 
位 置 的 ， 所 以 即使 连 上 了 也 不 知道 怎么 读 写 。 这 使 我 们 处 于 一 个 两 难 的 
境地 。 

1. 客户 端 

2. 客户 新 


通过 以 太 网 访问 文件 系统 ， 但 是 带宽 太 小 了 。 
从 FC 访问 LUN， 却 不 知道 文件 在 LUN 上 的 存放 位 置 。 
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Fibre Channel 


怎么 办 呢 ? 这 个 项 目 组 想到 了 一 个 办 法 。 他 们 把 以 太 网 和 FC 的 优 
势 结 合 起 来 。 先 通过 以 太 网 访问 文件 系统 ， 获 知 文件 存放 在 LUN 上 的 位 
置 ， 然 后 再 通过 FC 去 LUN 上 读 写 。 由 于 文件 位 置 的 数据 量 很 小 ， 所 以 
通过 小 带宽 的 以 太 网 也 能 快速 完成 ， 而 文件 内 容 的 数据 量 很 大 ，FC 的 
大 带宽 也 能 充分 发 挥 优势 。 根 据 这 个 原理 ， 项 目 组 开发 了 一 个 叫 





FMP (File Mapping Protocol) 的 网 络 协议 ， 专 门 用 于 客户 端 向 文件 系统 
查询 文件 的 存放 位 置 。 图 4 展示 了 增加 FC 连 接 后 的 拓扑 ， 即 两 种 网 络 协 
作 传 输 的 样子 。 


以 太 网 交换 机 
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网 络 存储 








SS 
DN FC 交换 机 


图 4 

访问 文件 当然 不 仅 是 读 写 内 容 这 么 简单 ， 还 要 操作 元 数据 和 避免 访 
问 冲 突 ， 等 等 。 当 时 CIFS 和 NFS 协 议 在 这 方面 已 经 很 成 熟 了 ， 所 以 FMP 
就 和 它们 结合 起 来 使 用 。 只 有 当 客 户 端 需要 恋 写 大 块 的 文件 内 容 时 才 调 
用 FMP， 然 后 再 通过 FC 访 问 其 文件 内 容 ， 其 他 时 候 照 样 走 CIFS 和 NFS 。 
举 个 例子 ， 如 果 我 们 看 中 了 文件 系统 里 一 部 10GB 的 电影 ， 那 就 通过 
FMP 获 得 该 电影 文件 在 LUN 上 的 存放 位 置 ， 然 后 再 通过 FC 快 速 地 下 载 
它 。 如 果 我 们 只 需要 读 一 个 I1KB 的 小 文件 ， 那 直接 通过 CIFS 或 NFS 吏 行 
了 ， 因 为 用 了 FC 也 不 见得 能 提高 多 少 性 能 。 换 句 话 说 ， 就 是 用 FMP 拓 
展 了 CIFS 和 NFS， 使 它们 适用 于 高 性 能 场合 。 

至 今 我 的 电脑 中 还 保存 着 一 份 FMP 网 络 包 。 如 图 5 所 示 ，Protocol 显 
示 为 FMP， 存 储 服务 器 通过 GetMap ”Reply 把 文件 内 容 在 LUN 上 的 位 置 
CExtent) 告知 客户 端 。 实 现 起 来 就 这 么 简单 。 











Fiter | fmp -| Expression... Clear Apply Save 





No, Time Source Destination Protocol Info 

27956 331.583083 Client Sserver FMP V3 GetMap Call (Reply In 27958) 
27958 331.583930 server Client FMP V3 GetMap Reply (Call In 27956) 
27959 331.672564 Client Sserver FMP V3 GetMap Call (Reply In 27961) 
27961 331.673070 server Client FMP V3 GetMap Reply (Call In 27959) 
27962 331.686955 Client Sserver FMP V3 GetMap Call (Reply In 27964) 
27964 331.687712 server Client FMP V3 GetMap Reply (Call In 27962) 
下 用 





由 Transmission Control Protocol, src Port: 4656 (4656), Dst Port: 1021 (1021) ， 
四 Remote Procedure Call, Type:Reply XID:0x51239349 
日 File Mapping Protocol 
[Program Version: 3] 
[Procedure: GetMap (8)] 
status: OK (0) 
Message Number: 175 
Cookie: Ox00000000 
File size: 1070735360 
Extent List Length: 5 
日 Extent (1) 
First Logical File Block: 22272 
Number of Blocks: 20 
Volume ID inside DART: Ox05b57a04 
start offset: 274892 
Extent State: VALID_DATA (0) 
田 EXtent (2) 
田 Extent (3) 
四 Extent (4) 











图 5 
FMP 刚 面世 的 时 候 颇 受 欢迎 ， 因 为 性 能 提升 太 明 显 了 ， 连 中 国 最 顶 
尖 的 科研 机 构 和 证 券 公司 都 在 用 它 ， 我 刚 毕 业 时 还 用 Wireshark 帮 它们 分 
析 过 几 次 FMP 包 。 用 我 国学 术 界 今年 流行 的 语言 来 说 ， 这 个 技术 也 算 
是 “突破 了 冯 : 诺 依 曼 瓶颈 的 束缚 ， 产 生 了 巨大 的 国际 影响 ”。 后 来 的 
pNEFS〈 即 NFSv4.1) 也 借用 了 它 的 理念 ， 图 6 中 的 LAYOUTGET 操 作 ， 
本 质 上 和 图 5 的 GetMap 就 是 异曲同工 。 





Filter: | nfs,main_opcode == 90 -| Expression... Clear Apply Savt 


No., Time SoUrcE Destination Protocol Info 


10 6. 342130000 Client Serwer NFS v4 call (Reply In 11) 
Tl 6.356517000 server client NFS V4 Reply (call In 10) 
19 9.195982000 client Server NFS V4 call (Reply In 20) 


20 9.210407000 server Client NFS V4 Reply {call In 19) 


LAYOUTGET 
LAYOUTGET 
LAYQUTGET 
LAYOUTGET 





4 时 Ml 


田 Remote Procedure call, Type:Ccall XID:0Ox86249770 
日 Network File system, Ops(3): SEQUENCE, PUTFH, LAYOUTGET 
[Program Version: 4] 
[Lv4 Procedure: COMPOUND (1)] 
Tag: <EMPTY> 
minorversion: 1 
日 Operations (count: 3): SEQUENCE, PUTFH, LAYOUTGET 
四 Opcode: SEQUENCE (53) 
四 Opcode: PUTFH (22) 
四 Opcode: LAYOUTGET (50) 
[Main Opcode: LAYOUTGET (50)] 





图 6 


可 惜 好景 不 长 ， 随 大 以 太 网 的 更 新 换代 ， 禹 宽 已 经 接近 甚至 超过 了 
FC。 现 在 单 用 NFS 或 CIFS 就 可 以 实现 很 高 的 性 能 ， 依 赖 FMP 的 场景 也 就 
越 来 越 少 了 ， 过 去 两 年 里 甚至 没有 一 家 公司 找 我 看 过 FMP 或 者 pNFS 的 
包 。 波 士 顿 附近 的 项 目 组 也 早 就 解散 ， 我 现在 只 能 从 旧 资 料 中 找到 这 几 
位 老 同事 的 名 字 : Jeff、Boris、Jason、Peter， 还 有 一 位 姓 Jiang 的 华人 。 
在 世界 IT 史上 ， 类 似 命运 的 优秀 产品 还 有 不 少 ， 美 好 而 短暂 ， 残 像 县 伦 
一 现 。 我 写 这 篇 文章 并 不 只 是 为 了 缅怀 这 个 我 付出 过 心血 的 协议 ， 也 想 











音 它 揭示 IT 界 一 个 普 般 规律 一 一 网 络 协议 的 面世 是 受 市 场 需求 驱使 的 。 
我 们 完全 可 以 根据 自己 的 需要 设计 一 个 新 协议 ， 不 要 以 为 这 是 遥 不 可 及 
的 事情 。 不 过 在 这 个 日 新 月 异 的 领域 中 ， 新 的 协议 可 能 很 快 整 会 老 去 ， 
而 老 协议 却 可 以 焕发 第 二 春 。 唯 一 能 青春 永 驻 的 ， 只 有 Wireshark 了 。 











、 » 
_ ye 
笑柄 


我 朋友 最 近 过 到 了 一 桩 怪事 ， 他 把 服务 器 的 网 络 从 干 兆 改造 成 万 
兆 ， 没 想到 用 户 纷纷 抱怨 性 能 下 降 。 于 是 他 不 得 不 降 回 千 兆 ， 用 户 们 反 
而 感觉 性 能 恢复 了 。 朋 友和 党 得 很 委 届 ， 不 明白 是 什么 原因 导致 他 好 心 共 
成 了 坏事 。 

改造 之 后 的 网 络 拓扑 大 体 如 图 1 所 示 。 区 换 机 和 服务 器 之 间 从 千 兆 
升 到 万 兆 了 ， 而 客户 端 和 交换 机 之 间 维 持 千 兆 不 变 。 














客户 端 交换 机 服务 器 


图 1 
我 分 析 了 改造 前 后 的 网 络 包 。 发 现 当 数据 从 客户 端 流 回 服 务 器 时 ， 
两 者 看 不 出 任何 差别 。 但 是 当 数 据 从 服务 器 流 癌 客户 端 时 ， 改 造 后 的 重 
传 率 明 显 增加 了 。 我 们 可 以 在 Wireshark 上 点 击 Analyze 沫 单 ， 再 点 击 


Expert Info 看 到 重 传统 计 ， 如 图 2 所 示 。 
(Weshert 4752 pent Ea [GCC] 











| Errors: 2 (6) |wamines 3 (159)| Notes: 121 (4587) |Chats: 0 (0) |Detaits: 4752 | Packet Comments: 0 | 
Group 4 Protocol 4 Summary 








习 Sequence TCP This frame is a (suspected) fast retransmission 





由 Sequence TCP This frame is a (suspected) retransmission 











Limit to display filter 




















这 里 要 补充 说 明 一 下 ， 只 要 很 少 的 丢 包 重 传 就 足以 对 性 能 造成 巨大 





影响 。 当 局 域 网 中 的 重 传 率 超 过 0.1% 就 值得 采取 措施 了 ， 人 快速 重 传 和 超 
时 重 传 的 影响 很 不 一 样 ， 所 以 这 个 经 验 值 仅 供 参 考 。 假 如 能 降低 到 零 当 
然 最 好 ， 但 实际 上 0.01% 以 下 的 重 传 率 是 很 难 消除 的 。 

从 Wireshark 看 到 重 传 现 象 之 后 ， 接 下 来 的 任务 就 是 找 出 为 什么 高 带 
宽 反 而 伴随 着 更 多 重 传 了 了。 我 的 猜测 是 换 成 万 兆 之 后 ， 服 务 占 的 发 送 速 
度 加 快 了 ， 但 由 于 客户 问 还 是 干 兆 的 ， 一 时 消化 不 了 这 么 多 ， 所 以 数据 
就 拥堵 在 交换 机 上 。 当 交换 机 的 缓冲 区 被 占 满 时 ， 就 不 得 不 把 包 丢 卸 ， 
从 而 导致 总 体 性 能 反而 不 如 改造 前 。 

网 络 理论 说 起 来 太 抽 象 了 ， 所 以 我 们 用 疼 3 来 辅助 理解 。 水 龙头 相 
当 于 服务 器 ， 漏 斗 相 当 于 交换 机 。 改 造 前 的 水 龙头 流速 和 漏斗 的 出 口 流 
速 保持 一 致 ， 所 以 虽然 不 快 但 也 不 至 于 溢出 。 把 水 龙头 改造 变 大 之 后 ， 
其 流速 超过 了 漏斗 出 口 的 流速 ， 因 此 过 了 一 段 时 间 水 就 会 溢出 漏斗 。 下 
次 你 开车 墙 在 下 高 架 的 下 道上 时 ， 也 可 以 体验 一 下 相同 的 拥 春 原理 。 











改造 前 改造 后 
图 3 
那 像 我 朋友 一 样 把 万 兆 改 回 千 兆 就 是 对 的 吗 ? 其 实 也 不 一 定 ， 假 如 


有 10 个 客户 端 同 时 从 服务 器 下 载 数据 ， 那 在 服务 器 上 用 万 兆 网 络 就 很 合 
适 ， 因 为 这 些 客户 端 可 以 平 挫 流 量 ， 数 据 束 不 会 拥堵 在 交换 机 上 。 这 相 
当 于 在 漏斗 上 再 挖 9 个 出 水 口 ， 也 束 不 会 洲 出 来 了 。 换 句 话 说 ， 服 务 器 
的 带宽 本 来 就 应 该 比 客户 端 大 才 合理 ， 尤 其 是 在 客户 端 特别 多 的 时 候 。 
不 过 为 了 避免 拥 寨 ， 最 好 设计 一 种 流 控 机 制 ， 允 许 交 换 机 在 过 载 时 通知 
服务 器 发 慢 一 点 ， 即 便 暂 停 传 输 的 效果 也 会 比 拥塞 丢 包 好 。 

IEEE 802.3x 所 定义 的 “暂停 帧 ”(Pause Frame) 就 实现 了 这 个 功能 。 

: 当 交 换 机 的 缓冲 区 即将 被 填 满 时 ， 它 可 以 给 服务 器 发 一 个 暂停 
帧 ， 让 它 等 得 一 会 再 发 。 这 样 就 避 倪 了 洲 出 丢 包 ， 从 而 避免 了 重 传 。 交 
换 机 在 等 待 时 间 里 会 继续 把 缓冲 区 的 数据 传 给 客户 端 ， 使 负担 得 以 释 
放 。 

:服务 器 需要 等 待 的 时 间 长 度 是 由 和 暂停 帧 指定 的 pause_time 指 定 的 。 
过 了 等 竺 时 间 之 后 ， 服 务 器 才 可 以 发 数据 。 

假如 交换 机 缓冲 区 里 的 数据 提前 消化 了 ， 它 还 可 以 给 服务 器 发 一 
个 pause_time 为 0 的 暂停 帧 ， 告 诉 服务 器 无 需 等 待 了 。 

我 的 实验 室 机 器 上 抓 不 到 和 暂停 帧 ， 因 为 它 太 底层 了 。 好 在 Wikipedia 
上 有 一 个 例子 ， 是 暂停 时 间 为 65535 guanta 的 (每 个 quanta 相 当 于 512 比 
特 时 间 ) ， 如 图 4 所 示 。 有 兴趣 分 析 这 种 包 的 话 ， 也 可 以 到 Wireshark 官 
网 下 载 示 例 包 。 
err 


Address: spanning-tree-(for-bridges)_01 (C01:80:c2:00:00:01) 
和 .. = IG bit: Group address (multicast/broadcast) 











rs ple cloballyauntiqveradd es Chactorsy detawu et 
日 Source: 42networ_30:41:50 (O00:0f:5d:30:41:50) 
Address: 42networ_30:41:50 (O00:0f:5d:30:41:50) 
er Oa i le a Tpit Tnalvidual audress (Cuniecast 
i a ordi pera srs wi Lilt Globall uaue adPess actor de at 
Type: MAC Control (Ox8808) 


Pause: OQxOI 





O01 
Quanta: 65535 


图 4 
和 暂停 帧 的 Destination MAC 地 址 固定 是 01-80-C2-00-00-01， 所 以 在 不 





同 的 环境 中 看 到 相同 的 地 址 也 不 要 党 得 奇怪 。 另 外 ， 和 暂停 帧 可 以 是 双 回 
的 ， 即 服务 器 在 必要 的 时 候 也 可 以 同 交 换 机 请 求 暂 停 。 

在 过 去 几 年 里 ， 我 在 不 少 生 产 环 境 中 利用 暂停 帧 解决 过 性 能 问题 。 
现在 FCoE (Fibre Channel over Ethernet) 技术 似乎 有 发 展 的 势头 ， 它 也 
需要 依赖 暂停 帧 来 绥 解 拥塞 ， 所 以 相信 和 暂停 帧 的 应 用 会 越 来 越 广 泛 的 。 
记 住 要 在 主机 和 交换 机 上 都 相应 配 好 ， 人 否则 是 不 会 起 效 的 ， 配 置 命令 请 
参照 厂商 提 供 的 手册 。 

从 暂停 帧 的 工作 原理 可 知 ， 它 适用 于 相 邻 设备 间 的 流 控 ， 所 以 在 图 
1 这 样 的 环境 中 可 以 工作 得 很 好 。 但 是 在 图 5 的 环境 中 ， 如 果 你 指望 它 从 
客户 端 一 路 影响 到 服务 器 ， 那 束 不 现实 了 。 只 有 TCP 层 的 流 控 ， 才 能 立 
即 作 用 于 整个 路 径 。 














客户 端 交换 机 路 由 器 路 由 器 交换 机 服务 器 


过 狐 不 及 


也 许 我 应 该 去 注册 一 家 公司 ， 专 门 提供 网 络 分 析 服 务 。 目 前 看 来 生 
意 应 该 会 不 错 ， 因 为 已 经 有 很 多 人 来 找 我 分 析 网 络 包 了 ， 有 的 居然 还 主 
动 要求 付 费 ， 让 我 觉得 技术 员 的 人 生还 是 有 一 点 点 希望 的 。 比 如 最 近 有 
个 中 东 公 司 的 远程 镜像 偏 慢 ， 研 究 了 很 久 都 没有 进展 ， 因 此 便 寄 希望 于 
Wireshark， 抓 了 个 包 给 我 分 析 。 

该 环境 的 网 络 拓扑 如 图 1 所 示 ， 主 数据 中 心 位 于 中 东 ， 需 要 定时 把 
新 数据 同步 到 瑞 国 去 ， 常 党 因为 传输 太 慢 而 同步 超时 。 




















中 东 英国 
图 1 
我 用 Wireshark 打 开 网 络 包 ， 找 到 Analyze -> Expert Info 染 单 选项 ， 果 
然 看 到 了 图 2 所 示 的 大 量 重 传 。 由 于 全 部 网 络 包 也 就 十 多 万 个 ， 这 个 重 
传 比例 已 经 算 相 当 高 了 。 
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Sequence TCP This frame is a (suspected) fast retransmission 
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图 2 
那 导致 重 传 的 人 呢 ? 当 我 点 Statistics “Conversations 荣 
X 台 服务 器 竞 然 用 了 


» 4/ 


单 选项 
50 个 TCP 连 接 玉 估 数 撕 司 上 步 。 




















TCP Conversations 
Address A 4 PortA 4 AddressB 4 PortB 4 Packets 4 Bytes 4 Packets A—B 4 Bytes A—B 4 Packets A~B 4 Bytes A~B < 
MiddleEast 47309 Britain 2051 3 388 2945 830 2811 670 134:[ 辕 
MiddleEast 49989 Britain 2051 3590 3214316 3081 322 132! 
Middle East Britain 2051 3679 3183 774 3010150 1731! 
Middle East Britain 2051 3574 3130 584 2994 062 136 : 


Middle East Britain 2051 3746 3 302 434 3148 778 1531 

Middle East Britain 2051 3408 2998 506 2853 590 144! 

Middle East Britain 3549 3100 630 2913 990 186( ~ 
上 








使 用 多 个 TICP 连 接 的 原因 不 难 理解 。 因 为 网 络 延迟 、 拥 塞 和 应 用 层 
设计 等 因 系 ， 单 个 连接 无 法 占 满 整个 物理 链 路 。 比 如 用 茶 坚 协议 传输 一 
连 串 字母 所 命名 的 小 文件 时 ， 在 链 路 上 可 能 形成 图 4 这 样 的 断断续续 的 
数据 流 ， 就 像 用 吸管 喝 饮 料 时 混 进 了 大 量 的 空气 。 


一 9 一 


图 4 








这 个 问题 的 确 是 可 以 通过 增加 一 些 连 接 数 占 满 链 路 来 解决 。 图 5 演 
示 了 增加 一 个 连接 后 的 状况 传输 的 是 一 连 串 数字 命名 的 文件 ) ， 可 见 
相同 时 间 里 传输 的 数据 总 量 增加 了 。 


图 5 

那 是 不 是 连接 数 越 多 越 好 呢 ? 从 理论 上 看 并 非 如 此 。 当 连接 数 多 到 
足以 占 满 整个 链 路 时 ， 再 增加 连接 就 没有 意义 了 ， 甚 至 可 能 带 来 负面 效 
果 。 这 是 由 以 下 原因 造成 的 。 

.多 个 连接 需要 更 高 的 资源 成 本 。 比 如 连接 的 建立 和 断 开 ， 以 及 维 
护 每 个 连接 需要 分 配 的 内 存 ， 都 会 消耗 服务 器 的 资源 。 

' 太 多 连接 抢占 同一 个 链 路 ， 有 可 能 会 增加 丢 包 率 。 就 像 用 多 辆 车 
来 运输 货物 可 以 加 快速 度 一 样 ， 当 和 车辆 多 到 足以 引发 交通 事故 时 就 适 得 
其 反 了 。 说 不 定 图 2 中 的 丢 包 就 有 一 部 分 是 过 多 的 连接 数 导 致 的 。 

以 上 只 是 理论 分 析 ， 我 决定 在 实验 室 中 粗略 模拟 一 下 。 该 实验 环境 
中 的 最 大 发 送 窗口 是 65535 字 节 ， 当 我 只 局 用 一 个 TCP 连 接 时 , “中 
东 ” 很 快 就 发 送 了 65535 字 节 的 “在 途 字 节 数 "”， 即 耗 光 了 发 送 窗 口 ， 因 此 
Wireshark 提示 LTCP window Fullj 〈 见 图 6) 。 这 种 情况 下 “中 东 ” 只 好 
停 下 来 等 待 “ 英 国 * 的 Ack， 收 到 Ack 后 才能 接着 往 下 传 。 这 也 说 明了 带 
宽 没 有 被 完全 利用 ， 应 该 增加 发 送 窗口 或 者 连接 数 来 补充 。 当 我 把 连接 
数 增加 到 3 个 时 ， 果 然 就 不 再 看 到 这 个 提示 了 。 














No. Time Source Destination Protocol Info 


71 0.392805000 Middle East Britain TCP [TCP Window Full] 64560-12345 [ACK] Seq=202344 Ack=1 
72 0.395142000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=142521 Win=65535 Len=0 
73 0.395219000 Middle East Britain TCP [TCP Window Full] 64560-12345 [ACK] seq=205200 Ack=1 
74 0.397470000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=145377 Win=65535 Len=0 
75 0.397549000 Middle East Britain TCP 64560-12345 [ACK] Seq=208056 Ack=1 
76 0.400139000 Britain Middle East TCP 12345-64560 [ACK] seq=1 Ack=148233 Win=65535 Len=0 
77 0.400218000 Middle East Britain TCP [TCP window Fu11] 64560-12345 [ACK] Seq=210912 Ack=1 
78 0.402431000 Britain Middle East TCP 12345-64560 [ACK] Seq=1 Ack=151089 Win=65535 Len=0 





| 四 





四 Checksum: Oxaddc [validation disabled] 
Urgent pointer: 0 

日 [SEQ/ACK analysis] 

[iRTT: 0.040996000 seconds] 








图 6 
注意 : Wireshark 提 示 的 LTCP window Full」 和 [LTCP zerowindow ] 意义 不 同 ， 但 是 有 很 多 


人 会 混淆 。 前 者 表示 这 个 包 的 发 送 方 意识 到 “在 途 字 节 数 ”已 经 达到 对 方 所 声明 的 接收 窗口 ， 不 

能 再 发 了 ， 而 后 者 表示 这 个 包 的 发 送 方 意识 到 自己 的 缓存 区 已 经 满 了 ， 无 法 接收 更 多 数据 。 
启用 3 个 TCP 连 接 时 的 性 能 如 图 7 所 示 ， 为 5.055 Mbit/s， 跟 理想 速度 

很 接近 【该 公司 租用 的 带宽 确实 小 了 点 ) ， 此 时 在 包 里 也 没有 看 到 重 














Display filter: none 
IJgnored packets: 0 (0.00030) 


Traffic 4 Captured 4 Displayed 4 Displayed % 4 Marked 4 Marked % 4 
Packets 2534 2534 100.0003% 0 0.000% 
Between first and last packet 7.904 sec 


Avg. packets/sec 320.604 

Avg. packet size 1971 bytes 

Bytes 4994424 4994424 100.0003% 
Avg. bytes/sec 631899.786 

Avg. MBit/sec 5.055 








而 当 连 接 数 增 加 到 50 个 时 ， 就 降 到 了 图 8 所 示 的 4.081 Mbit/s 了 ， 基 
不 多 20% 的 幅度 ， 同 时 也 出 现 不 少 重 传 〈 重 传 图 就 不 贴 出 来 了 ) 。 可 见 


实验 结果 和 我 们 的 理论 分 析 一 致 。 


PE 


| Display 
Display filter: none 
lgnored packets: 0 (0,000%) 








Traffic 4 Captured 4 Displayed 4 Displayed % 4 Marked 4 Marked % 4 
Packets 13623 13623 100,000% 0 0.000% 
Between first and last packet 34.745 sec 


Avg. packets/sec 392.088 

Avg. packet size 1301 bytes 

Bytes 17722364 17722364 100.000% 0 
Avg. bytes/sec 510073.000 

Avg. MBit/sec 4.081 





图 8 

以 上 分 析 ， 从 理论 到 实验 都 说 明了 连接 数 并 非 越 多 越 好 。 那 究竟 多 
少 是 最 合适 的 呢 ? 这 和 网 络 带 宽 、 往 返 时 间 以 及 发 送 窗口 都 有 关系 。 我 
没有 固定 的 计算 公式 ， 只 能 一 边 调节 连接 数 一 边 观 测 ， 测 到 最 佳 性 能 时 
的 那个 连接 数 就 是 了 。 本 文 开头 提 到 的 那个 “中 东 - 英 国 ” 镜 像 问 题 ， 后 
来 也 是 这 样 调 优 的 。 不 过 这 种 调 优 一 般 提 升幅 度 有 限 ， 对 于 很 多 中 东 土 
豪 公司 来 说 ， 最 直截了当 的 方式 还 是 购买 带宽 和 加 速 器 。 

看 到 这 里 ， 你 可 能 会 想起 在 中 国 很 流行 的 多 线程 下 载 工 具 ， 其 原理 
是 否 也 是 通过 提高 链 路 利用 率 来 提升 速度 呢 ? 比如 家 里 装 了 百 兆 宽带 ， 
用 单线 程 下 载 电 影 的 时 候 只 有 100KB/s， 用 了 双 线 程 就 能 接近 200KB/s 
了 。 这 个 原理 其 实 和 本 文 所 分 析 的 很 不 一 样 ， 因 为 它 的 性 能 瓶颈 并 不 在 
链 路 或 者 网 络 协议 上 ， 而 是 服务 器 给 每 个 连接 所 设置 的 速度 限额 。 要 是 
在 服务 器 上 解除 了 限额 ， 那 很 可 能 单线 程 的 性 能 也 可 以 超过 200KB/s。 














治 疗 9 里 白 下 


作为 理性 程度 排行 第 二 的 天 蝎 座 和 男生， 我 当然 不 相信 星座 学 说 ， 更 
无 法 理解 处 女 座 们 为 什么 宣称 自己 有 强迫 症 。 其 实 即使 是 轻 度 的 强迫 症 
都 非常 痛 苗 ， 经 党 遭受 到 各 种 细节 的 折磨 ， 尤 其 是 我 这 种 连 技术 领域 都 
逃 不 过 的 患者 。 举 个 简单 的 例子 ， 十 多 年 前 我 第 一 次 编辑 网 络 共 享 文件 
时 就 很 焦虑 ， 担 心 其 他 人 也 同时 在 编辑 该 文件 ， 保 存 时 会 发 生 冲 突 。 这 
种 担忧 挥 之 不 去 ， 以 至 于 每 次 都 要 把 共享 文件 移 到 本 地 人 硬盘， 等 编辑 好 
了 再 移 回去 。 

人 们 处 理 焦 虑 的 方式 各 有 不 同 ， 有 些 人 喝 唱 咖啡 晒 晒 太阳 就 觉得 岁 
月 静 好 了 。 可 惜 我 就 做 不 到 这 一 点 ， 一 定 要 把 细节 都 理 清 楚 才 能 治愈 ， 
多 年 下 来 竟然 也 * 被 迫 ?学 了 不 少 知 识 。 比 如 前 面 提 到 的 共享 文件 的 保 
存 ， 如 果 用 Wireshark 探 完 一 下 ， 会 友 现 满 满 都 是 技术 含量 ， 设 计 恨 好 的 
软件 能 完全 避免 我 所 担心 的 意外 。 如 果 你 需要 开发 一 个 处 理 文件 的 软 
件 ， 也 可 以 参 (shin) 考 〈zhii) 这 些 设计 。 本 文 就 通过 几 个 简单 的 实 
验 ， 分 析 一 下 Notepad、Notepad++ 和 Microsoft Excel 在 保存 文件 时 的 不 
同 表 现 。 

Notepad 实 验 

1. 让 小 明和 小 红 分 别 在 自己 的 电脑 上 用 Notepad 打 开 同 一 个 共享 文 
件 \10.32.106.84\nas_share\Home\test\abc.txt。 

2. 小 明 写 上 一 句 “ 我 是 小 明 ” 并 保存 ， 然 后 小 红 写 上 一 句 “ 我 是 小 
红 ” 并 保存 。 

3. 两 人 都 天 掉 文 件 之 后 再 打开 ， 发 现 只 有 小 红 写 的 那 句 话 保存 下 
来 了 。 














从 实验 结果 可 见 ，Notepad 完 全 没有 保护 机 制 ， 所 以 虽然 两 个 人 都 
保存 成 功 ， 但 小 明 保 存 的 内 容 被 小 红 保 存 的 履 亲 了。 这 种 事情 过 到 一 次 
就 会 给 强迫 症 患 者 留 下 一 辈子 的 阴影 。 

Notepad++ 实 验 

1. 让 小 明和 小 红 分 别 在 自己 的 电脑 上 用 Notepad++ 打 开 同 一 个 共享 
文件 \10.32.106.84\nas_share\Home\test\abc.txt。 

2. 小 明 写 上 一 句 “ 我 是 小 明 ” 并 保存 ， 这 时 候 小 红 的 NotePad++ 弹 出 
图 1 所 示 的 提示 。 








[ 1 W1032.106.84\nas_share\Home\test\abc,.bt 


This file has been modified by another program,. 


Do you want to reload it? 


图 1 

3. 小 红 点 击 Yes 加 载 了 小 明 编 辑 过 的 内 容 ， 再 写 上 一 句 “ 我 是 小 
红 ” 并 保存 。 

4. 两 人 都 关 掉 文件 之 后 再 打开 ， 发 现 两 句 话 都 被 保存 下 来 了 。 

从 实验 结果 可 见 ，Notepad++ 有 不 错 的 保护 机 制 ， 所 以 不 会 导致 数 
据 丢 失 。 那 它 是 怎样 实现 这 个 机 制 的 呢 ? 用 Wireshark 看 看 就 知道 了 。 我 
在 小 红 的 电脑 上 启动 抓 包 ， 发 现 当 小 明 点 击 保存 时 ， 文 件 服务 器 给 小 红 
的 电脑 发 了 一 个 Notify Response， 即 通知 她 文件 abc.txt 被 改动 了 【〈 见 图 2 











右 下 角 ) 。Notepad++ 收 到 这 个 Notify 之 后 ， 就 可 以 提示 小 红 重 新 加 载 文 
件 内 容 了 。 原 理 就 是 这 么 人 简单。 


No Time Source Destination Protocol Info 
1 0.000000000 File_server Xiaohong SMB2 Notify Response 
2 0.000618000 xiaohong File_server SMB2 Notify Request 








NetBIOS Session service 

日 SMB2 (Server Message Block Protocol version 2) 
SMB2 Header 
日 Notify Response (OxOf) 








0000 44 39 c4 50 a9 f6 ec 30 91 e3 a6 80 08 00 45 00 D9.P...0 ...... Es 
0010 00 8e e3 0a 00 00 3a 06 56 b4 0a 20 6a 54 0a 20 : i 5 
0020 “Cc8 17 呆 强 江 丰 革 要 于 村 村 EE 
0030 EE 00 00 00 62 Te 23 4d 42 40 00 
0040 00 00 00 00 00 00 of 00 00 00 03 00 00 00 00 00 
0050 00 00 if 04 00 00 00 00 00 00 3b 00 00 00 03 00 
0060 00 80 01 00 00 00 0a 02 00 00 00 00 00 00 00 00 
0070 00 00 00 00 00 00 00 00 00 00 09 00 48 00 la 00 
0080 00 00 00 00 00 00 03 00 00 00 0e 00 00 00 61 00 
0090 62 00 63 00 2e 00 74 00 78 00 74 00 


图 2 








Excel 实 验 
1. 让 小 明 在 自己 的 电脑 上 用 Excel 打 开 共 享 文件 
\10.32.106.84\nas_share\Home\test\test.xlsx 并 编辑 。 
2. 让 小 红 也 打开 同一 个 文件 ， 结 果 收 到 了 图 3 所 示 的 提示 ， 说 明 小 
明 把 文件 锁定 了 ， 不 允许 其 他 人 同时 编辑 。 
File in Use 


test, xlsx is locked for editing 


by xiaoming ， 


Dpen Read-Onlyw or did: 'Notify’ to open read-only and receive notification 
when the document is no longer in Use， 





图 3 
由 实验 结果 可 见 ，Excel 的 保护 机 制 更 加 严密 且 贴 心 ， 连 谁 在 编辑 
该 文件 都 提示 出 来 了 。 因 此 小 红 可 以 根据 提示 找到 小 明 ， 让 他 赶紧 编辑 
好 然后 关 掉 。 那 么 问题 来 了 ，Excel 是 怎样 做 到 这 一 切 的 呢 ? 我 在 小 红 





的 电脑 上 抓 了 个 包 ( 见 图 4〉， 发 现 她 在 打开 test.xlsx 时 ， 会 尝试 创建 一 
个 叫 一 $test.xlsx 的 临时 文件 。 而 因为 该 文件 已 经 被 其 他 人 创建 并 锁定 ， 
所 以 小 红 收 到 了 “STATUS_SHARING_VIOLATION” 的 报错 。 接 着 小 红 
读 出 一 $test.xlsx 的 内 容 ， 得 到 了 锁定 者 的 名 字 《 见 图 4 右 下 角 的 


Xiaoming) 。 











No. Time Source Destination Protocol Info 
121 0. 543945000 xiaohong File_server SMB2 Create Request File: Home\test\~$test.xl1sx 
122 0. 544708000 File_server xiaohong SMB2 Create Response, Error: STATUS_PENDING 
123 0.545529000 File_server Xiaohong SMB2 Create Response, Error: [STATUS_ SHARING VIOLATION 
125 0. 546684000 Xxiaohong File_server SMB2 Create Request File: 
126 0.547681000 File_server Xiaohong SMB2 Create Response File: 
127 0. 547922000 xiaohong File_server SMB2 Close Request File: 
128 0.548450000 File_server xiaohong SMB2 Close Response 
129 0.549457000 xiaohong File_server SMB2 Create Request File: Home 
130 0.550251000 File_server xiaohong SMB2 Create Response File: Home 
131 0.551476000 xiaohong File_server SMB2 Close Request File: Home 
132 0.551716000 xiaohong File_server SMB2 Create Request File: Home\test\~$test.xlsx 
133 0.552214000 File_server xiaohong SMB2 Close Response 
134 0.552413000 xiaohong File_server SMB2 Create Request File: Home\test 
135 0.552443000 File_server Xiaohong SMB2 Create Response, Error: STATUS_PENDING 
136 0.553227000 File_server Xiaohong SMB2 Create Response File: 
138 0.553292000 File_server Xiaohong SMB2 Create Response File: Home\test 
139 0.553447000 xiaohong File_server SMB2 Read Request Len:165 off:0 File: 
140 0.553467000 xiaohong File_server SMB2 Close Request File: Home\test 
142 0.554411000 File_server Xiaohong SMB2 Read Response 
< Ui 
00c0 20 08 00 78 00 69 00 61 00 6f 00 6d 00 69 00 6e 
00d0 00 67 00 20 00 20 00 20 00 20 00 20 00 20 00 20 
mm me TIN nm mm nana IN NN 下 人 AN IN ANAM TAR mm HN NN oN 





是 
我 在 小 明 的 电脑 上 也 抓 了 包 。 从 图 5 可 见 的 确 是 他 创建 了 一 
$test.xlsx 并 在 里 面 写 上 了 目 己 的 名 字 。 








No. _ Time Source Destination Protocol Info 

239 5.995377000 Xiaoming File_server SMB2 write Request Len:165 off:0 File: Home\test\~$test.xlsx 
240 5.995938000 File_server Xiaoming DCERPC Response: call_id: 2, Fragment: single, Ctx: 0 

241 5.995997000 File_server Xiaoming SMB2 write Response 





站 由 








6e 67 

20 
20 20 20 
00 7 
00 20 
00 20 


00b0 
00c0 
00d0 
00e0 
00f0 
0100 











分 析 到 这 里 ， 我 们 就 知道 了 Excel 是 怎样 防止 共享 文件 被 意外 覆盖 
的 ， 因 此 编辑 时 再 也 不 用 焦虑 了。 我 们 还 可 以 根据 这 个 机 制 设计 一 些 办 
公 室 恶作剧 。 比 如 说 ， 小 明 可 以 在 Excel 的 选项 窗口 中 把 用 户 名 改 成 大 
老板 的 名 字 〈 见 图 6 确 部 )， 这 样 其 他 人 打开 该 文件 时 就 会 以 为 是 大 老 
板 正 在 编辑 了 ， 只 好 干 等 着 。 











General options for working with Excel, 


Formulas 


Proofing User jnterface options 





Save Show Mini Toolbar on selection © 
Enable Live Preview © 


Language 
Color scheme: 


Adv: d 
ie ScreenTip style: | Show feature descriptions in ScreenTips [=| 








Customize Ribbon 
When creating new workbooks 


Use this font: Body Font EE 
Add-Ins 
Font size: 11 | 


Th ers Default view for new sheets: | Normal View [=| 
Include this many sheets: 


Personalize your copy of Microsoft Office 


User name: |Big Boss 


Quick Access Toolbar 











图 6 
本 文 只 是 Wireshark 在 反 向 工程 上 的 简单 应 用 。 如 果 你 对 这 方面 很 感 
兴趣 ， 完 全 可 以 用 它 来 研究 其 他 软件 ， 有 些 真 的 可 以 调查 到 很 深入 的 程 
度 。 





前 几 天 被 卷 入 了 一 场 辨 论 ， 起 因 是 有 人 说 四 十 岁 还 在 写 代 码 便 是 人 
生 输家 。 我 当然 是 站 在 反方 的 ， 这 年 类 坐 在 电脑 面前 就 可 以 建设 社会 ， 
既 有 成 就 感 还 能 养家 糊口 的 职业 有 多 少 ” 3W 咖 啡 馆 里 那么 多 怀 撕 idea 的 
创业 青年 ， 都 只 差 一 个 程序 员 就 可 以 改变 世界 了 ， 还 不 够 你 自 肾 的 吗 ? 
不 过 反方 提出 的 一 些 论据 也 很 不 科学 ， 比 如 吹 咕 目 己 吴 边 的 老 工 程 师 有 
多 牛 多 牛 ， 好 像 工 龄 长 了 都 能 修 烁 成 仙 一 样 。 这 一 点 我 在 刚 毕 业 时 就 很 
不 以 为 然 ， 今 天 就 借 一 个 Wireshark 案 例 表 达 一 下 我 的 看 法 。 

这 是 我 刚 参 加 工作 不 和 久 的 事情 。 当 时 我 还 在 休假 ， 老 板 的 电话 就 退 
杀 过 来 了 ， 说 是 有 位 大 客户 发 斋 ， 发 来 一 封 措 群 极其 严厉 的 邮件 ， 导 致 
我 司 没有 工程 师 敢 再 跟 他 对 话 了 。 由 于 该 邮件 中 贴 了 很 多 Wireshark 截 
图 ， 所 以 老板 觉得 由 我 来 回应 好 一 些 。 

虽然 有 被 迫 出 全 的 感觉 ， 但 我 还 是 仔细 读 了 那 封 邮件 。 原 来 事情 是 
这 样 的 : 这 位 客户 买 了 我 司 最 高 端的 服务 器 ， 可 是 上 线 后 发 现 性 能 不 太 
好 ， 于 是 融 投 诉 了 。 我 司 的 技术 文 持 认 为 瓶 儒 是 在 网 络 上 ， 与 服务 器 无 
天 。 客 户 闻 之 大 悉 ， 说 自己 已 经 分 析 过 网 络 包 ， 发 现 是 服务 器 的 缓存 太 
小 导致 的 ， 因 为 TCP 接 收 窗口 最 大 只 有 16KB 如 图 1 方 框 所 示 〉。 











No. Time Source Destination Protocol Info 

112 0.001260000 Client Server TCP [TCP segment of a reassembled PDU] 

113 0.001261000 Client Server TCP [TCP segment of a reassembled PDU] 

114 0.001450000 Server Client TCP 445-63225 [ACK] Seq=4244945014 Ack=105065333 Win=16384 
115 0.001450000 Server Client TCP 445-63225 [ACK] Seq=4244945014 Ack=105068253 Win=16384 
阳 


Frame 114: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 
Ethernet II，Src: Cisco_e3:a6:80 (ec:30:91:e3:a6:80), Dst: Universa_50:a9:f6 (44:39:c4:50:a9:f 
Internet Protocol Version 4, Src: Server (10.32.106.84), Dst: Client (10.32.200.23) 
Transmission Control Protocol, Src Port: 445 (445), Dst Port: 63225 (63225), Seq: 4244945014 ， 
Source Port: 445 (445) 
Destination Port: 63225 (63225) 
[Stream index: 0] 
[TCP segment Len: 0] 
sequence number: 4244945014 
Acknowledgment number: 105065333 
Header Length: 20 bytes 
习 . . . 。 0000 0001 0000 = Flags: Ox010 (ACK) 
[Calculated window size: 16384] 
Window size scaling factor: -1 (unknown)] 


图 1 

这 个 截图 果然 把 技术 支持 镇 住 了 ， 因 为 Wireshark 是 不 会 骗 人 的 ， 
16KB 的 确 是 太 小 了 啊 。 它 意味 着 客户 端 每 及 16KB 的 数据 就 不 得 不 集 下 
来 等 待 服务 器 的 Ack， 我 一 台 廉 价 笔记 本 的 接收 窗口 都 不 只 64KB 呢 。 更 
糟糕 的 是 ， 这 位 在 签名 档 中 特意 注 明 了 “首席 工程 师 ” 的 客户 很 不 配合 ， 
嫌 技 术 文 持 的 资历 太 浅 。 整 封 邮件 用 词 之 傲 娇 ， 语 气 之 自信 ， 让 我 等 新 
毕业 和 后 望 而 生 芋 。 说 实话 ， 我 之 前 见 过 的 活 人 中 ， 只 有 理发 师 是 有 首席 
头衔 的 。 幸 好 本 人 脸皮 够 厚 ， 而 且 擅长 在 复杂 的 纠纷 中 过 滤 出 纯 技 术 部 
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:从 Wireshark 可 见 服务 器 的 TCP 接 收 窗口 的 确 很 小 ， 这 也 是 客户 的 
论据 。 

接收 窗口 太 小 肯定 会 影响 网 络 性 能 。 

当前 网 络 性 能 的 确 是 很 差 。 

这 个 推理 过 程 看 起 来 没有 问题 ， 我 只 能 从 最 初始 的 论据 着 手 研究 了 
一 一 服务 器 的 接收 窗口 真 的 很 小 吗 ? 仔细 分 析 之 后 ， 我 发 现 还 真 不 一 
定 。 请 看 图 1 底部 的 Wireshark 提 示 : “window size scaling 
factor: -1(unknown)”， 我 当时 也 不 懂 是 什么 意思 ， 只 是 觉得 有 必要 搞 清 
楚 ， 碍 了 很 多 文档 后 才 知 道里 头 大 有 文章 。 











在 TCP 协 议 刚 被 发 明 的 时 代 ， 全 世界 的 带宽 都 很 小 ， 因 此 不 能 一 口 
气 向 网 络 中 发 送 大 量 数据 。 基 于 这 个 原因 ，TCP 头 中 只 给 接收 窗口 预 留 
了 16 个 比特 ， 这 就 意味 着 它 最 大 只 能 表示 2 -1=65535 字 节 。 随 着 人 硬件 
的 革命 性 进步 ， 网 络 带 宽 越 来 越 大 ，65535 字 市 已经 不 够 用 了 。 那 有 什 
么 办 法 可 以 扩展 接收 窗口 呢 ? TCP 头 里 是 肯定 没有 多 余 的 空间 了 ， 上 所 以 
RFC 1323 提供 了 一 个 有 创意 的 方案 ， 就 是 在 三 次 握手 时 双方 都 把 一 个 
HU “Window Scale" 的 值 告知 对 方 。 对 方 收 到 后 会 把 这 个 值 当 作 2 的 指 
数 ， 算 出 来 的 值 再 作为 接收 窗口 的 系数 。 有 了 这 个 系数 就 可 以 把 接收 窗 
口 扩展 好 多 倍 了 。 

理论 说 起 来 有 点 复杂 ， 我 们 举 个 实际 的 例子 ， 图 2 是 三 次 握手 的 过 
程 ， 服 务 器 在 2 号 包 中 声明 它 的 Window Scale 为 3， 于 是 客户 端 收 到 后 就 
把 3 作为 2 的 指数 ， 算 得 23 等 于 8。 在 此 后 的 传输 过 程 中 ， 客 户 端 收 到 服 
务 器 所 声明 的 接收 窗口 就 会 自动 乘 以 8。 比 如 在 接 下 来 的 3569 号 包 中 
〈 见 图 3) ， 服 务 器 声明 其 接收 窗口 为 16384， 那 客户 端 就 知道 其 真实 的 
接收 窗口 应 该 是 16384x8=131072， 从 而 突破 了 65535 的 限制 。Wireshark 
也 是 根据 三 次 握手 里 看 到 的 Window Scale 值 帮 我 们 计算 的 ， 然 后 在 括号 
中 提示 出 来 〈 注 意 ， 当 你 在 Wireshark 里 看 到 一 个 括号 ， 那 往往 意味 着 其 
内 容 是 附加 提示 ， 而 不 是 网 络 包 本 身 的 内 容 ) 。 


No，_ Time Source Destination Protocol Info 
1 0.000000000 Client server TCP 63225-445 [SYN] Seq=104758059 Win=8192 Len=0 MSS=1460 
2 0.000791000 server Client TCP 445-63225 [SYN, ACK] Seq=4243639809 Ack=104758060 Win: 
3 0.000840000 Client server TCP 63225-445 [ACK] Seq=104758060 Ack=4243639810 Win=6553! 
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= Options: (liZ Dytes), Maximum segment size, NO-Operation (NOP), NO-Operation (NOP), SACK perm 
H Maximum segment size: 1460 bytes 
习 No-Operation (NOP) 
习 No-Operation (NOP) 
TCP SACK Permitted Option: True 
二 i NOP 





图 2 


No. Time Source Destination Protocol Info 

3567 16.396874000 Client server TCP [TCP segment of a reassembled PDU] 

3568 16.396875000 Client server TCP [TCP segment of a reassembled PDU] 

3569 16.397462000 server Client TCP 445-63225 [ACK] Seq=4244945014 Ack=105041973 
3570 16. 397463000 Server Client TCP 445-63225 [ACK] Seq=4244945014 Ack=105044893 
* Mh 





AcCKnowiedgment number: 1I105041973 
Header Length: 20 bytes 

习 ...。0000 0001 0000 = Flags: 0x010 (ACK) 
Wina 16384 









图 3 

于 是 问题 来 了 ， 如 果 在 三 次 握手 之 后 才 开 始 抓 包 会 怎么 样 ? 不 难 想 
象 ， 因 为 Wireshark 无 从 知晓 Window ”Scale 的 值 ， 所 以 就 无 法 计算 出 系 
数 ， 只 好 显示 出 没有 系数 时 的 大 小 ， 图 1 中 的 “window size scaling 
factor: -1(unknown)” 正 好 提示 了 这 种 情况 。 这 也 说 明 图 1 显示 的 “window 
size value: 16384” 是 因为 Wireshark 只 看 到 了 这 个 值 ， 但 不 意味 着 真实 的 
接收 窗口 就 是 16384 字 节 。 客 户 听 了 这 些 分 析 后 悦 然 大 悟 ， 完 全 瑟 记 我 
是 刚 毕 业 的 ， 很 配合 地 去 查 他 的 网 路 瓶 贷 了 ， 最 后 果然 发 现 问 题 根源 和 
服务 器 无 关 。 可 见 只 要 技术 研究 得 足够 深入 ， 资 历 都 可 以 当 作 浮云 。 

现在 的 我 已 经 不 会 因为 工龄 受到 攻 视 了 ， 有 些 客户 甚至 要 叫 我 叔 
叔 ， 但 类 似 遭 遇 还 是 会 发 生 在 年 轻 的 同事 身上 。 这 也 不 是 中 国 特有 的 问 
题 ， 似 乎 东方 文化 都 特别 重视 工龄 。 有 一 次 请 日 本 同事 吃饭 ， 才 知道 他 
们 出 电梯 时 竟然 要 以 “ 社 龄 ?为 顺序 ， 由 入 职 早 的 “前 辈 " 走 在 前 面 。 幸 好 
我 也 算 老 人 了 ， 盏 则 就 显得 很 不 礼貌 。 

也 许 这 也 算是 对 经 验 的 一 种 尊重 吧 ， 但 我 觉得 没 必 要 重视 成 这 样 ， 
更 不 应 该 歧视 新 人 。 工 龄 的 确 可 以 累积 经 验 ， 但 不 一 定 能 提高 多 少 技 
能 ， 就 像 你 花 足 够 多 的 时 间 也 可 以 把 相对 论 背 诵 下 来 ， 但 物理 水 平 不 会 
因此 提高 多 少 。 我 见 到 过 最 闫 敬业 业 的 老 工 程 师 ， 简 直 就 是 一 个 活体 知 
识 库 ， 遇 到 很 多 问题 都 能 在 笔记 本 中 翻 出 解决 方案 来 。 可 是 遇 到 新 问题 
他 束 解 决 不 了 ， 因 为 没有 深入 钻研 问题 的 习惯 ， 对 工具 (比如 
Wireshark) 也 不 感 兴趣 。 假 如 这 位 工程 师 和 一 个 喜欢 动脑 筋 的 应 届 生 应 



































聘 同 一 职位 ， 我 会 曼 不 犹 殉 地 选择 应 届 生 ， 因 为 专业 知识 容易 补 ， 钻 研 
精神 却 很 难 养 成 ， 很 可 能 一 年 后 两 个 人 的 水 平 就 兰 不 多 ， 再 过 一 年 就 舟 
反超 了 。 何 况 工龄 长 的 人 也 不 一 定 束 经 验 丰富 。 在 一 个 职位 末了 很 多 年 
的 人 ， 有 可 能 是 因为 爱 册 敬业 ， 也 可 能 是 因为 实在 太 弱 了 了， 一 直 想 跳 模 
却 没 成 功 ( 我 又 暴露 刻薄 的 本 性 了 ) 。 











作为 一 名 高 尚 的 工程 师 ， 我 们 当然 要 勇于 承担 贡 任 ， 这 几乎 是 业内 
第 一 美德 。 不 过 只 需 承担 自己 的 那 部 分 束 够 了 ， 不 要 把 别人 的 也 拭 到 号 
上 ， 让 真正 的 责任 方 来 承担 才 最 科学 。 

然而 划分 员 任 并 不 容易 。 现 在 一 套 I 系 统 往往 涉及 多 个 厂商 的 产 
品 ， 比 如 Oracle 的 数据 库 装 在 了 EMC 的 存储 上 ， 然 后 用 Cisco 的 网 络 设备 
来 做 远程 镜像 。 项 目 签收 时 各 家 销售 都 很 开心 ， 但 等 到 出 问题 时 就 轮 到 
售后 头疼 了 。 比 如 数据 库 的 远程 镜像 老 是 同步 不 了 ， 底 层 原 因 又 不 是 一 
眼 就 能 看 出 来 的 ， 这 种 情况 应 该 由 谁 来 负责 呢 ? 假设 故障 点 是 在 网 络 
上 ， 那 让 Oracle 的 工程 师 来 排查 反而 耽误 时 间 了 ， 难 不 成 每 次 事故 都 要 
组 织 大 会 诊 吗 ? 还 好 有 了 Wireshark， 划 分 责任 就 简单 多 了 ， 只 要 抓 包 分 
析 就 行 。 本 文 分 享 的 便 是 这 样 一 个 案例 。 

我 司 做 容 灾 产品 的 售后 部 门 最 近 接 到 一 个 投诉 ， 说 远程 镜像 死活 建 
不 起 来 。 技 术 文 持 工 程 师 非常 尽职 ， 仔 细 地 检查 了 所 有 配置 ， 发 现 都 是 
对 的 ; 又 测试 了 网 络 连 接 ， 也 都 ping 得 通 一 一 总 之 看 上 去 似乎 什么 都 是 
好 的 ， 但 就 是 建 不 起 来 。 一 般 远 程 镜像 的 网 络 环境 不 会 很 复杂 ， 束 是 通 
过 层 层 路 由 ， 把 数据 从 生产 服务 器 复制 到 灾 备 服务 器 上 ， 如 图 1 所 示 。 
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生产 服务 器 路 由 器 网 络 专线 路 由 器 灾 备 服务 器 
图 1 

怎么 办 呢 ? 你 可 能 会 觉得 凡是 林 沛 满分 享 的 案例 都 是 先 抓 个 包 ， 然 

后 英明 神武 地 用 Wireshark 解 决 掉 了 (希望 没有 给 各 位 留 下 这 样 自 吹 自 擂 





























的 印象 ) 。 不 过 这 次 却 有 点 狼 狐 ， 我 的 确 在 生产 服务 器 上 抓 了 包 ， 但 是 

并 没有 看 出 原因 。 截 图 见 图 2， 生 产 环境 〈Prod_Server) 的 部 分 数据 包 

发 到 灾 备 服务 器 〈DR_Server) 之 后 ， 收 到 了 大 量 的 RST 〈 即 RESET) 

回复 ， 说 明 被 拒绝 了 。 

No, Time Source Destination Protocol Info 
24 3.042969 Prod_server DR_Server TCP 54395~8888 [ACK] seq=46613 Ack=291 Win=139 
25 3.042969 DR_Server Prod_server TCP 8888-~-54395 [ACK] Seq=291 Ack=32133 Win=209 
26 3.042969 Prod_server DR_Server TCP 54395-~8888 [ACK] Seq=55301 Ack=291 Win=139 
27 3.042969 “DR_Sserver Prod_server TCP 8888-54395 [ACK] Seq=291 Ack=36477 Win=209 
28 3.042969 Prod_server DR_Server TeP 54395~8888 Seq=63989 Ack=291 Win=139 
29 3.046875 DR_Server Prod_server TCP 8888--54395 seq=291 Win=262144 Len=0 
30 3.046875 DR_Server Prod_server TCP 8888-54395 
31 3.046875 DR_Server Prod_server TCP 8888-54395 
32 3.046875 DR_Server Prod_server TCP 8888-54395 


33 3.046875 DR_Server Prod_server TCP 8888--54395 
34 3.046875 DR_Server Prod_server TCP 8888-54395 


图 2 

客户 斩钉截铁 ,，“ 你 看 一 目 了 然 吧 ，Wireshark 上 带 RST 标 志 的 包 明 
显 都 是 从 灾 备 服务 器 发 出 来 的 ， 所 以 就 是 你 们 的 设备 有 问题 ， 应 该 由 你 
们 来 负责 。” 我 对 他 的 推理 无 力 反 驶 ， 的 确 应 该 到 灾 备 服务 器 上 检查 配 
置 和 日 志 。 这 可 把 我 们 的 技术 支持 急 坏 了， 因为 他 在 灾 备 服务 器 上 完全 
查 不 出 问题 。 

我 们 似乎 走 进 了 一 条 死胡同 。Wireshark 把 原因 指向 了 灾 备 ， 但 我 们 
在 灾 备 上 又 没有 发 现 问题 。 走 投 无 路 之 际 ， 我 只 好 从 头 再 杭 理 一 和 过， 看 
看 有 没有 漏 挥 什么 。 最 后 还 真 让 我 想到 一 个 可 能 性 一 一 虽然 在 生产 服务 
器 上 看 到 了 RST 包 ， 但 这 并 不 能 证 明 该 包 一 定 就 是 从 灾 备 发 过 来 的 。 假 
如 是 网 络 路 径 上 的 茶 个 设备 伪装 成 灾 备 发 的 ， 那 就 不 算 我 们 的 责任 啦 ， 
应 该 在 两 边 的 服务 器 上 同时 抓 包 才能 判断 。 技 术 文 持 工 程 师 也 没有 更 好 
的 办 法 ， 只 好 照办 了 ， 喜 讯 也 很 快 传 来 : 灾 备 那 边 果然 没有 发 过 RST 
包 ， 客 户 在 铁证 面前 也 认同 了 我 们 的 观点 。 这 员 任 推 色 得 堪 称 完美 。 

既然 和 我 司 无 和 关 ， 我 也 就 不 再 关注 这 件 事 情 了 。 没 想到 几 天 后 和 同 
事 吃 饭 时 ， 听 说 这 案子 还 没有 了 了结。 仔细 打 听 了 一 下 ， 原 来 客户 不 知道 
怎样 定位 发 RST 的 那 台 设备 ， 所 以 问题 还 是 解决 不 了 。 帮 人 帮 到 底 ， 能 








seq=291 Win=262144 Len=0 
Seq=291 Win=262144 Len=0 
Seq=291 Win=262144 Len=0 
seq=291 Win=262144 Len=0 
Seq=291 Win=262144 Len=0 

















人 否 用 Wireshark 来 辅助 定位 呢 ? 我 们 研究 了 一 下 ， 发 现 还 是 可 以 的 : 根据 
RFC 1812， 一 个 网 络 包 的 TITL 每 减 去 1 就 意味 着 它 经 过 一 次 路 由 。 接 下 
来 我 们 再 看 图 3，RST 包 的 TTL 为 62。 由 于 TIL 的 初始 值 一 般 为 64， 那 就 
说 明 很 可 能 是 距离 生产 服务 器 两 跳 〈64-62=2) 的 那 台 设备 发 出 来 的 。 
客户 只 需 翻 出 网 络 拓扑 图 ， 就 能 大 概 知道 是 哪 台 设备 了 。 











No, Time Source Destination protocol Info 
27 3.042969 DR_server Prod_server TCP 8888-54395 [ACK] Seq=29] 
28 3.042969 Prod_server DR_SerVver TCP 54395~8888 [ACK] Seq=63¢ 
29 3.046875 ”DR_Server Prod_server “TCP 8888-~54395 [RST] seq=29 
30 3.046875 DR_Server Prod_server TCP 8888-54395 [RST] Seq=291 
31 3.046875 DR_Server Prod_server TCP 8888-54395 [RST] Seq=291 
32 3.046875 ”DR_Server Prod_server TCP 8888-54395 [RST] Seq=291 





‘ | 中 


Identification: 0x000d (13) 
由 Flags: 0x00 


Fragment offset: 0 


Protocol: TCP (6) 








图 3 

这 个 案子 就 此 结束 了 ， 说 破 了 似乎 很 简单 ， 但 是 刚 遇 到 时 确实 很 迷 
洗 。 事 实 上 当 我 想到 TIL 的 时 候 ， 已 经 意识 到 刚 开始 的 建议 是 不 对 的 ， 
没 必 要 两 边 同时 抓 包 ， 直 接 对 比 生 产 服务 占 上 抓 到 的 正常 包 和 RST 包 就 
行 了 。 正 常 包 的 TTL 请 见 图 4， 说 明生 产 服务 器 和 灾 备 服务 絮 之 间 跨 了 6 








味 k。 

No. Time Source Destination Protocol Info 
27 3.042969 ”DR_SerVver Prod_server TCP 8888-54395 [ACK] Seq=291 Ack=36477 Win=204 
28 3.042969 Prod_server DR_Server TCP 54395~8888 [ACK] Seq=63989 Ack=291 Win=13( 
29 3.046875 DR_Server Prod_server TCP 8888-54395 [RST] Seq=291 Win=262144 Len=0 
30 3.046875 DR_Server Prod_server TCP 8888-54395 [RST] Seq=291 Win=262144 Len=0 
31 3.046875 DR_Sserver Prod_server TCP 8888-54395 [RST] seq=291 Win=262144 Len=0 
32 3.046875 DR_Sserver Prod_server TCP 8888-54395 [RST] Seq=291 Win=262144 Len=0 





< | UL 





Identification: Ox6da6 (28070) 
田 Flags: 0x00 


于 
图 4 
这 个 技巧 还 可 以 运用 到 其 他 的 场景 中 ， 比 如 前 几 天 有 朋友 说 百度 的 
JS 被 动 持 来 攻击 GitHub， 我 立即 告诉 他 可 以 抓 包 看 TTL。 后 来 该 方法 被 
国外 一 些 技术 人 员 证 实时 ， 这 位 朋友 简直 惊 采 了 ， 以 为 我 有 多 厉害 。 其 





实 我 是 先 花 了 很 多 时 间 在 这 个 案子 上 才 琢 磨 出 来 的 。 套 用 一 句 有 点 诬 的 
心灵 鸡汤 ， 就 是 “ 台 上 一 分 钟 ， 台 下 十 年 功 。>” 


一 个 面试 建议 


在 应 聘 一 个 技术 职位 之 前 ， 做 好 充分 的 准备 无 疑 能 大 大 提高 成 功 
率 。 这 里 所 说 的 准备 并 不 是 指 押 题 ， 因 为 有 经 验 的 面试 官 往往 准备 了 海 
量 的 题库 ， 押 中 的 概率 太 低 。 比 如 我 有 位 同事 的 题库 里 有 上 百 道 题 ， 内 
容 涵盖 了 编程 、 操 作 系 统 、 网 络 、 存 储 .……. 每 次 他 就 抽出 十 道 来 问 ， 连 
合作 多 年 的 我 都 猜 不 出 他 下 一 次 会 问 哪些 。 

那 完 竟 应 该 准备 什么 呢 ? 以 我 个 人 的 招聘 经 验 ， 最 值得 花 时 间 的 就 
是 忆 结 自己 过 去 的 工作 成 果 ， 因 为 这 在 面试 官 心目 中 有 举足轻重 的 地 
位 。 从 一 个 人 过 去 的 工作 经 历 中 ， 能 看 出 他 的 贡 任 心 、 钻 研 精神 、 技 术 
视野 、 交 流 能 力 ， 等 等 ， 比 知识 储备 更 有 价值 。 比 如 很 多 美国 的 面试 官 
于 欢 问 ,“ 你 在 工作 中 过 到 过 什么 环 手 事情 吗 ? 最 后 是 怎么 解决 的 ? "十 
万 不 要 以 为 这 只 是 走过场 的 题目 而 随便 应 付 。 事 实 上 这 就 是 你 发 挥 的 最 
好 机 会 ， 正 确 的 表现 应 该 是 作 沉 思 状 ， 稍 等 片刻 再 回答 , “我 处 理 过 不 
少 有 挑战 性 的 问题 ， 比 如 有 关 xxx 的 ， 不 知道 您 对 这 方面 是 否 感 兴 
趣 ? ”这 个 回答 会 显得 你 拿 得 出 手 的 东西 有 很 多 ，xxx 只 是 其 中 之 一 。 也 
不 用 担心 面试 官 会 对 它 不 感 兴趣 ， 此 刻 他 们 正 伪装 成 无 所 不 知 的 上 第 ， 
无 论 你 说 什么 ， 他 们 都 会 显 出 很 懂 的 样子 , “Wow， 这 是 很 知名 的 技 
术 ， 我 很 想 听 听 。” 于 是 你 事先 准备 好 的 材料 就 可 以 拿 出 来 显摆 了 ， 要 
牢记 以 下 几 点 : 

问题 描述 要 引人入胜 。 确 保 这 个 环 手 的 问题 是 再 符 的 面试 官 都 能 
听 懂 的 ， 比 如 服务 器 访问 拒绝 、 网 络 性 能 下 降 ， 等 等 。 同 时 又 必须 足够 
诡异 ， 比 如 同样 配置 的 两 台 服 务 右 表现 完全 不 同 。 你 多 看 儿 期 《 走 近 科 
学 》， 就 能 理解 这 个 技巧 有 多 重要 ， 无 论 多 普通 的 事情 都 要 描述 得 绘 声 






































绘 色 。 只 要 勾 起 了 面试 官 的 好 奇 心 ， 他 们 就 会 在 不 知 不 觉 中 和 你 站 到 一 
起 ， 而 不 是 居高临下 地 审问 。 

: 抓 住 互动 的 机 会 。 面 试 官 们 往往 会 忍 不 住 点 评 一 下 ， 甚 至 秀一 下 
知识 ， 这 是 技术 人 员 的 通病 。 要 抓 住 这 个 机 会 把 他 拉 进 来 讨论 ， 你 可 以 
这 样 附 和 , “对 对 对 ， 我 当时 的 看 法 和 您 一 样 ， 但 是 .……….” 一 起 探索 同一 
个 问题 非常 有 助 于 拉 近 你 们 的 心理 距离 。 

-拒绝 浮夸 。 真 实 的 内 容 才 可 能 让 有 经 验 的 面试 官 信服 。 假 如 让 对 
方 意识 到 有 添 油 加 柄 的 成 分 ， 肯 定 会 大 大 减 分 。 

分 享 技术 。 这 些 案例 一 定 要 有 技术 含量 ， 比 如 最 终 在 Wireshark 中 
发 现 某 个 异常 现象 ， 再 结合 协议 细节 找到 了 根本 原因 。 这 样 可 以 让 面试 
官 在 学 习 到 新 知识 的 同时 ， 也 感受 到 你 的 钻研 精神 。 如 果 他 第 一 次 见面 
就 能 从 你 这 里 学 到 有 价值 的 知识 ， 自 然 会 希望 以 后 能 跟 你 一 起 工作 。 即 
使 该 知识 对 他 没什么 实际 价值 ， 能 跟 一 个 有 和 钻研 精神 和 分 享 精神 的 人 合 
作 也 是 令 人 愉悦 的 。 

以 我 自己 为 例 ， 我 多 年 前 应 聘 一 个 心仪 的 职位 时 ， 最 后 一 轮 的 面试 
官 是 个 美国 geek， 提 问 角度 刁钻 无 比 ， 因 此 我 大 多 没有 回答 出 来 ， 现 场 
写 的 程序 也 出 错 了 。 最 后 他 估计 也 不 抱 希 望 了 ， 象 征 性 地 让 我 讲 讲 工作 
中 解决 过 的 棘手 问题 ， 我 当时 很 不 识 相 地 说 , “我 遇 到 过 不 少 关 于 TCP 
协议 的 ， 不 知道 您 是 否 有 兴趣 昕 听 ?” 没 想到 这 哥们 说 ,，“ 噢 ， 我 的 博士 
论文 就 是 和 TCP 协 议 有 关 的 ， 很 想 听 听 你 对 这 方面 的 见解 。” 我 立即 懂 
了 ， 屋 漏 俩 逢 连夜 雨 ， 吹 牛 碰 到 老 熟 人 ， 只 好 硬 着 头皮 讲 了 一 个 杀身 经 
历 过 的 性 能 优化 案例 。 神 奇 的 是 这 个 案例 竟然 改变 了 面试 结果 ， 正 因为 
他 很 懂 TCP， 上 所 以 对 这 个 问题 很 感 兴趣 ， 也 能 体会 我 在 优化 过 程 中 的 努 
力 。 最 后 甚至 站 起 来 跟 我 讨论 了 很 多 细节 ， 在 白板 上 画 了 一 个 模型 图 跟 
我 探讨 。 到 了 面试 结束 时 还 意犹未尽 ， 跟 我 说 了 一 句 意味 深长 的 
话 , “ 剩 下 的 问题 等 你 来 上 班 继续 聊 。” 我 就 知道 offer 到 手 了 。 几 周 后 我 
第 一 天 上 班 ， 他 果然 来 找 我 聊天 ， 其 中 有 一 句 话 我 至 今 还 记得 , “虽然 
































你 当时 有 很 多 问题 没 答 出 来 ， 但 是 最 后 那个 案例 体现 了 很 好 的 钻研 精 
神 ， 让 我 意识 到 之 前 问 你 的 题目 没有 选 对 。” 面 试 官 们 真正 重视 的 是 什 
么 ， 由 此 可 见 一 斑 。 

这 些 道 理 听 上 去 很 简单 ， 然 而 当 你 着 手 准 备 面试 材料 的 时 候 ， 可 能 
会 发 现 没什么 拿 得 出 手 的 。 这 又 是 什么 原因 呢 ? 不 是 因为 你 平时 碌碌 无 
为 ， 而 更 可 能 是 因为 没有 总 络 的 习惯 ， 时 间 一 长 都 志 了 。 这 就 是 坚持 写 
技术 博客 的 价值 之 一 ， 能 用 自己 的 语言 表达 出 来 才 算 真正 理解 并 且 记 住 
了 。 写 作 能 强迫 思考 ， 对 于 真正 有 技术 含量 的 东西 ， 你 会 在 写作 过 程 中 
加 深 理解 ， 从 此 就 款 不 抒 了 ;而 技术 含量 不 高 的 东西 ， 你 写 个 开头 目 然 
会 停 笔 ， 从 此 筷 拓 也 无 所 谓 。 不 仅 技 术 上 如 此 ， 其 他 学 科 也 一 样 ， 年 轻 




















的 时 候 阅 读 国学 经 典 ， 每 篇 都 让 人 党 得 顿悟 了 人 生 。 但 如 宁 试 痢 把 感受 
写成 文章 ， 驶 会 发 现 所 谓 的 顿悟 只 是 一 碗 心灵 鸡汤 。 






























































2]. 本 文 的 “拥塞 点 ”翻译 自 英 文 文档 中 的 “congestion point， 表 示 的 是 一 个 国 值 。 在 
当中 也 党 用 “拥塞 点 ?来 表 示 “ 发 生 拥 塞 的 节点 ”>， 即 “congestion node”。 在 此 要 把 定义 交代 清楚 ， 
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J Wireshark 


Wireshark 不 只 应 用 于 企业 级 数据 中 心 。 在 高 度 依赖 于 网 络 的 现代 生 
活 中 ，Wireshark 也 有 广阔 的 用 武之 地 ， 无 其 是 当前 越 来 越 流行 的 手机 应 
用 。 这 一 部 分 介绍 了 如 何在 家 中 搭建 一 个 环境 来 抓 取 手 机 上 的 WiFi 网 络 
包 ， 分 析 了 微 博 和 微 信 等 不 同 App 的 网 络 行为 ， 揭 露 了 家 性 宽带 如 何 被 
恶意 劫持 等 。 这 一 部 分 技术 含量 不 一 定 很 高 ， 但 是 比较 有 趣 。 











央视 的 【每 周 质量 报告 】 做 过 一 期 关于 网 络 的 节目 ， 叫 “ 假 宽 人 带 真 
相 ”。 大 意 是 说 某 些 运营 商 的 带宽 远 远 达 不 到 其 承诺 的 标准 ，360 的 测速 
软件 也 “有 明显 的 设计 缺陷 "”， 所 以 测 出 的 结果 远 高 于 真实 带宽 。 

难得 有 个 业内 大 新 闻 ， 我 当然 不 会 错过 ， 当 即 就 用 Wireshark 验 证 了 
一 下 。 这 一 试 才 知 道 ， 原 来 网 络 测速 包含 了 不 少 有 意思 的 知识 点 ， 所 以 
便 写 出 来 和 大 家 分 享 。 

我 家 当时 用 的 是 中 国电 信 的 10M 宽 带 ， 从 官网 测 到 的 结果 如 图 1 所 
示 ， 下 载 速 度 达 到 1235KB/ 秒 ， 差 不 多 是 10OM 了 。 在 不 同时 间 段 测试 都 
是 一 样 的 结果 ， 所 以 应 该 是 可 信 的 。 
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本 次 测试 数值 : 平均 1235KB7 秒 ， 约 为 9_6W 第 宽 。 
圈 ”同时 测 1 式 上 传 速率 





8 所 


风骨 








加 下 载 速 度 加 上 传 速度 
平均 值 : 1235 了 /种 平均 值 : 271 王 /种 
峰 值 : 1419IB/ 种 峰 “” 值 : 333 亚 /种 
查看 带宽 换算 去 
图 1 


注意 : 中 国 特色 的 宽带 服务 是 以 下 载 速度 为 计算 标准 的 ， 其 实 上 传 速度 慢 很 多 ， 上 下 行 带 

宽 严 重 不 对 等 。 这 就 是 为 什么 会 在 图 1 中 看 到 上 传 速度 只 有 2M。 本 文 不 关注 这 一 点 ， 所 以 只 分 
析 下 载 速度 。 

这 个 速度 究竟 是 怎样 测 出 来 的 呢 ? 我 用 Wireshark 抓 了 个 包 ， 且 看 下 
面 的 详细 分 析 。 

点 击 Wireshark 的 Statistics 菜 单 ， 再 点 击 Conversations 选 项 ， 可 以 得 
到 图 2 所 示 的 窗口 。 从 中 可 见 测速 过 程 中 用 到 了 5 个 TCP 连 接 在 下 载 。 
为 端口 号 是 80， 所 以 应 用 层 协议 应 该 是 HITP。 

















一 A 
[Etheret: 3| Fibre Channel| FDDi | Ipvé: 10 | ipv6| Ipx | JxTa | NCP | Rsvp| scrp| Tcp: 22 | Token Ring| Upp:1| use| wuan 


TCP Conversations 








| AddressA 4 port/ 上 4 AddressB 4 Port 4 Pacl 4 Bytes Y Packets A—B 4 BytesA 一 B 4 Packets A~B 4 Byte' < 
中 | 192.168.0.102 54350 101.95.50.3 6 368 802 2662 158 118 ( 国 
| | 192168.0102 54351 101.95.503 5 410 103 2267 134 727 
192.168.0.102 54347 101.95.50.3 4 230 479 1 835 109 741 

192.168.0.102 54348 101.95.50.3 3 740 504 1 573 92 992 

192.168.0.102 54346 101.95.50.3 3 088 534 1221 72 264 

| 

















Name resolution 回 Limit to display filter 


| _ Help Copy 




















FollowStream | | GraphA-B | | GraphA~B 

图 2 

为 什么 要 选择 5 个 连接 ， 而 不 是 更 多 或 者 更 少 呢 ? 其 实 连 接 数 的 选 
取 很 有 讲究 。 之 所 以 不 用 单个 连接 ， 是 因为 一 个 连接 不 可 能 时 刻 都 在 传 
输 ， 有 很 多 原因 会 导致 它 不 得 不 短暂 停 清 。 当 某 一 个 连接 停 清 时 ， 其 它 
的 连接 还 可 以 继续 传输 ， 这 样 束 能 最 大 限度 地 利用 带宽 。 在 《固定 宽带 
接 入 速率 测试 方法 》 通 信行 业 标准 中 ， 也 明确 规定 了 “测试 中 使 用 的 线 
程 数量 为 N (N>4) ”。 











图 3 是 其 中 一 个 连接 的 Time/Sequence Number 坐 标 图 ， 我 是 在 
Wireshark 中 点 击 Statistics -, TCP StreamGraph » Time-Sequence 


Graph (Stevens) 沫 单 来 生成 它 的 。 
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图 3 

对 这 个 连接 而 言 ， 传 输 过 程 中 遭遇 了 多 次 停 清 ， 比 如 最 严重 的 是 
0.3 一 7.8 秒 之 间 ，Sequence 值 几乎 没有 增长 。 还 好 其 他 TCP 连 接 在 这 段 时 
间 里 仍 在 正常 传输 ， 所 以 带宽 一 点 都 没有 浪费 。 之 所 以 没有 用 更 多 的 连 
接 数 ， 是 因为 多 到 一 定 程度 就 没有 意义 了 ， 其 至 会 影响 TCP 的 拥塞 控制 
效果 。 我 用 iPerf 测 试 过 的 ， 详 情 可 见 本 书 的 《过 犹 不 及 》 一 文 。 究 竟 用 
多 少 个 连接 数 最 好 ， 这 是 需要 测试 的 ， 估 计 技 术 人 员 测 下 来 的 最 佳 连接 
数 是 5。 随 着 百 兆 家 庭 带宽 的 普及 ， 相 信 我 们 以 后 会 看 到 更 多 的 连接 
数 。 

再 回 到 Wireshark 的 主 界面 。 如 图 4 所 示 ， 在 下 载 测 试 开始 之 前 ， 客 
户 端 是 用 一 个 GET 方 法 查 到 下 载 源 的 ， 即 http:/101.95.50.3/test.img。 直 











接 用 了 P 的 办 法 不 错 ， 因 为 不 会 受到 DNS 会 询 时 间 的 影响 。 


No. Time Source Destination Protocol Info 
9 0.300174000 192.168.0.102 218.1.60.39 HTTP GET /speed/PluginaAccessLimit.do?method=acquire&uip=KD10230 
10 0.304187000 218.1.60.39 192.168.0.102 Tp [TCP Dup ACK 8#1] 80-54345 [ACK] Seq=266 Ack=1558 Win=8704 
11 0.304189000 218.1.60. 39 192.168.0.102 TCP 80~54345 [ACK] Seq=266 Ack=3138 Win=11520 Len=0 
218.1.60.39 192.168.0.102 HTTP HTTP/1.1 200 OK (application/json) 


12 0.327770000 





= Wh 
日 Object 
日 Member Key: “id” 
string value: 6585031 


日 Member Key: "ur1” 
http://101.95. 50.3/test. img 


string value: 





图 4 
获知 下 载 源 之 后 ， 就 可 以 建立 5 个 TCP 连 接 下 载 了 。 图 5 是 其 中 的 一 
个 连接 ， 从 Time 一 栏 可 见 响应 速度 相当 快 ，GET 请 求 发 出 去 3.1 毫 秒 后 
( 即 16 号 包 和 18 号 包 之 间 的 时 间 差 ) 就 开始 收 到 数据 了 。 这 是 因为 
101.95.50.3 位 于 上 海 电 信 的 机 房 中 ， 离 我 家 不 远 。 而 且 这 应 该 是 一 台 专 
门 用 来 提供 测速 的 服务 器 ， 很 可 能 被 全 面 优化 过 了 。 不 过 再 怎么 优化 都 














不 算 作 浆 ， 


电信 承诺 的 10M 本 来 束 是 理想 状态 下 的 市 完 。 看 来 央视 曝光 
的 假 带宽 问题 没有 发 生 在 我 号 上 。 





No. Time Source Destination Protocol Info 
13 0.420906000 192.168.0.102 101.95.50.3 TCP 54346~80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PE 
14 0.424337000 101.95.50.3 192.168.0.102 TCP 80-54346 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1412 
15 0.424425000 192.168.0.102 101.95.50.3 TCP 54346-80 [ACK] Seq=1 Ack=1 Win=66364 Len=0 
16 0.426084000 192.168.0.102 101.95.50.3 HTTP GET /test.img?q=0.2612285758368671 HTTP/1.1 
17 0.428562000 101.95.50.3 192.168.0.102 TCP 80-54346 [ACK] Seq=1 Ack=415 Win=15744 Len=0 
18 0.429200000 101.95.50.3 192.168.0.102 TCP [TCP segment of a reassembled PDU] 
19 0.429270000 101.95.50.3 192.168.0.102 TCP [TCP segment of a reassembled PDU] 
20 0.429299000 192.168.0.102 101.95.50.3 TCP 54346-~80 [ACK] Seq=415 Ack=2825 Win=66364 Len=0 
21 0.429380000 101.95.50.3 192.168.0.102 TCP [TCP segment of a reassembled PDU] 
22 0.429520000 101.95.50.3 192.168.0.102 TCP [TCP segment of a reassembled PDU] 
23 0.429545000 192.168.0.102 101.95.50.3 TCP 54346-~80 [ACK] Seq=415 Ack=5649 Win=66364 Len=0 
24 0.429638000 101.95.50.3 192.168.0.102 TCP [TCP segment of a reassembled PDU] 
25 0.429809000 101.95.50.3 192.168.0.102 TCP [TCP segment of a reassembled PDU] 


营 商 、 跨 区 域 和 服务 器 性 能 
卡 。 








那 作为 第 三 方 的 360 测 速 
下 载 到 了 两 个 360 测 速 软件 ， 先 来 看 第 





他 宽 并 不 意味 着 上 什么 网 都 | 


天 。 








A 
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就算 你 家 日 





有 100M 宽 带 ， 


图 5 
影响 性 能 体验 的 因素 很 多 ， 除 了 带宽 ， 还 有 跨 运 


靠 VPN 连 到 国外 网 站 看 视频 也 可 能 很 














为 3M， 略 低 于 电信 官网 的 宣称 值 。 


东软 件 是 否 真 的 “有 明显 的 设计 缺陷 ” 呢 ? 我 


一 个 。 如 图 6 所 示 ， 测 出 来 的 带宽 


必 网 吉 测 试 工具 Er. 
当前 网 络 环境 下 , 下 载 的 速度 能 达到 : 1MB/ 秒 


报时 到 于 痪 带 ”J 计 囊 J 


器 网 速 曾 起 结果 说 明 
您 的 网 速 在 : 8M ADSL 和 专线 之 间 。 
属于 较 快 的 宽带 上 网 速度 范围 内 ， 能 流畅 的 浏览 网 负 ， 看 在 线 视频 和 玩 网 络 游 
焉 。 

》 网 速 不 错 ? 通过 论坛 、 微 博 告 诉 其 他 人 》 测速 结果 保存 为 图 片 
~ 加 快 上 网球 度 的 建议 


公 常 不 会 受到 占 网 速 程 序 的 景 弗 ， 但 如 果 感 觉 上 网 速度 出 现 剧 常 、 绎 慢 的 情况 ， 
可 以 定期 查看 流量 上 监控 。 


重新 出 坛 | | 退出 
图 6 


于 是 再 用 Wireshark 分 析 。 从 图 7 可 见 ，360 测 速 软件 也 选择 了 5 个 
TCP 连 接 来 下 载 ， 端 口号 也 是 80， 与 电信 的 方式 如 出 一 斩 。 原 理 是 一 模 
- 样 ， 差 别 只 是 服务 器 的 响应 速度 ， 电 信和 服务 器 为 3.1 毫 秒 ，360 服 务 器 
则 是 4.9 坚 秒 ， 这 也 许 就 是 结果 略 有 不 同 的 原因 。 有 具体 网 络 包 和 图 5 很 
像 ， 为 了 不 浪费 篇 幅 我 就 不 贴 出 来 了 。 











TCP Conversations 
Address A PortA 4 AddressB 4 PortB 4 Packets 4 Bytes v Packets A—B 4 BytesA—B 4 Packets A~B 4 Bytes A~B « 
192.168.0.102 52618 101.227.15.3 80 1106 741 265 668 
192.168.0.102 52619 101.227.15.3 80 1013 720 883 653 
192.168.0.102 52617 101.227.153 80 995 714789 
192.168.0.102 52616 101.227.15.3 80 1008 698 025 
192.168.0.102 52620 101.227.15.3 80 976 686122 





加 Name resolution Limit to display filter 








图 7 

从 这 个 工具 看 ，360 测 速 软 件 并 不 存在 央视 所 说 的 “明显 的 设计 缺 
陷 ?， 人 否则 电信 官网 也 算 设计 缺陷 。 于 是 我 决定 试 一 下 另 一 个 360 测 速 工 
具 。 从 图 8 可 见 ， 其 结果 接近 10M。 


多 360 宽 带 测速 器 创建 桌面 图 标 | 微 博 分 享 X 


席 帝 接 入 速度 长 途 网 络 速度 网 速 排 行 榜 


网 络 最 大 接 入 速度 为 《 己 【MB/ 秒 ， 相 当 于 8M~10M 宽带 








拨号 ”512K 窝 带 1M 帘 带 ”2M 宽带 ”4M 宽带 ”10M 宽带 ”专线 


当前 的 网 速 就 像 淡 租 的 速度 ， 领 先 于 全 国 95% 的 用 户 ! 


-2) 近期 网 证 晶 按 次 显示 己 按 天 显示 





1.5MB 下 载 速度 为 1.21 MB/ 种 | 








再 用 Wireshark 分 析 。 从 图 9 可 见 ， 这 次 除了 HTTP 下 载 ， 还 有 不 少数 
据 是 通过 P2SP 的 ， 传 输 层 走 的 是 UDP 协议 。 央 视 的 专家 估计 也 看 到 这 个 
现象 ， 所 以 认为 这 是 一 个 设计 缺陷 ， 说 “这 种 P2SP 测 速 方法 ， 它 会 去 选 
择 一 些 同样 安装 了 这 款 软件 的 其 他 的 连接 节点 来 进行 测速 ， 只 要 其 中 有 
一 个 节点 ， 它 是 在 这 个 用 户 同一 个 小 区 宽带 的 子 网 里 面 ， 它 的 这 个 链 路 
质量 惑 非常 好 ， 网 速 就 非常 快 ”。 我 有 点 怀疑 这 个 猜测 ， 因 为 一 个 小 区 
里 有 多 个 用 户 安装 测速 软件 的 概率 太 低 了 。 我 自己 测 了 几 次 的 结果 都 差 


不 多 ， 假 如 真有 一 个 市 把 在 我 们 小 区 里 ， 应 该 能 从 图 9 的 统计 表 中 看 出 
这 个 “ 作 次 *IP 的 流量 。 
Ta Ra 


[Ethemet: 5 | Fibre Channe!| FDDI[ipvts378[ipv6[IpX[JxrA[Ncp[Rsvp| scrp| Tcp:84 | Token Ring| upp:353 |usb] 

















UDP Conversations 

AddressA 4 PortA 4 AddressB 4 portB 4 Pacl 4 Bytes Y PacketsA—B 4 BytesA—B 4 Packets A~B 4 Byt 
106.118.175.90 61487 192.168.0.102 10102 591 529147 401 513 221 190 
192.168.0.102 10102 182.200.188.88 10100 468 462142 133 11 230 335 
192.168.0.102 10102 113.26.217.39 10100 465 453 782 138 11 849 327 
14.208.249.79 10106 192.168.0.102 10102 265 232417 172 224 463 93 

| 192.168.0.102 10102 113,69.20.255 1948 273 231 636 186 224 613 87 

| 42.92.132.89 10640 192.168.0.102 10102 240 218 815 162 212 164 78 

| | 180.111.109.197 10102 192.168.0.102 10102 198 196174 57 4603 141 

图 9 


综 上 所 述 ，360 测 速 软件 还 是 有 节操 的 ， 它 体现 的 是 模拟 现实 的 网 
速 ， 包 括 HITP〈 浏 览 网 页 和 有 刷 微 博之 类 的 ) 和 P2SP《〈 比 如 迅雷 下 
载 ) 。 运 营 商 提供 的 测速 也 没有 作 浆 ， 不 过 它 体现 的 是 一 个 接近 理想 状 
况 的 网 速 。 那 为 什么 央视 说 有 些 宽 带 不 达标 ， 但 360 测 速 软 件 却 给 出 很 
高 的 带宽 呢 ? 我 认为 这 不 是 P2SP 导 致 的 ， 而 是 因为 这 些 运 营 商 侦查 到 
360 正 在 测速 ， 于 是 立即 劫持 ， 转 变 成 在 限 速 点 之 内 测速 了 。 如 果真 是 
这 样 ， 那 也 是 运营 商 的 问题 ， 不 能 怪 测 速 工 具 。 由 于 我 没 抓 到 这 种 包 ， 
所 以 就 不 多 作 评 论 。 

最 后 声明 一 下 ， 我 写 这 篇 文章 的 目的 不 是 给 上 海 电 信 做 广告 或 者 为 
360 正 名 ， 只 是 想 借 助 这 个 话题 演示 一 下 Wireshark 的 应 用 场景 。 几 乎 所 
有 和 网 络 相关 的 问题 都 可 以 用 Wireshark 来 探索 学 习 ， 有 时 候 稍 微分 析 一 
下 就 能 看 得 很 远 。 我 对 带宽 缺 厂 短 两 也 不 在 乎 ， 因 为 从 来 不 下 载 电影 或 
者 美剧 。 网 络 的 安全 和 通畅 才 是 我 最 重视 的 ， 可 惜 这 两 点 并 不 容易 享受 
到 。 




















手机 抓 包 


我 很 人 以前 残 想 在 手机 上 抓 包 了 。 因 为 随 着 移动 App 的 流行 ( 见 图 
1) ， 手 机 的 流量 越 来 越 大 ， 值 得 研究 的 技术 问题 也 会 越 来 越 多 。 像 我 
这 样 还 未 融入 现代 社会 的 大 叔 ， 每 个 月 都 能 用 掉 儿 百 兆 流量， 那些 摩登 
青年 的 流量 之 大 可 想 而 知 。 
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不 过 作为 晚期 拖延 症 患 者 ， 我 迟 迟 没有 付 诸 行动 ， 直 到 有 一 天 手机 
上 的 某 个 App 英 名 其 妙 地 耗 挥 了 近 百 兆 流量 ， 才 不 得 不 动手 。 我 先 打 了 
个 电话 给 中 国 移动 ， 客 服 人 员 说 , “我 们 最 近 收 到 很 多 例 类 似 的 报告 
了 ， 原 因 还 没有 但 明 。” 好 吧 ， 看 来 只 能 由 我 自己 来 但 了 ， 顺 便 搭建 一 
个 可 以 在 手机 上 抓 包 的 环境 。 

一 番 研 究 之 后 ， 我 大 概 知道 了 业内 人 士 都 是 怎么 抓 包 的 。 

:多数 开 发 人 员 用 Fiddler 和 Charles 来 抓 ， 包 括 安 时 和 iPhone。 可 惜 它 
们 都 是 针对 Web 的 ， 不 能 满足 我 的 全 部 需求 。 

.有 人 说 设 个 HTTP 代理 就 可 以 在 电脑 上 抓 了 ， 不 过 我 感 兴趣 的 协议 
不 只 是 HTTP。 


.有 一 些 现成 的 安 卓 抓 包 工具 ， 但 需要 root 才 能 装 。iOS 上 的 工具 则 
没有 找到 。 

: 搜 到 了 一 球 叫 tPacketCapture 的 工具 ， 号 称 无 需 root 也 能 抓 ， 可 是 我 
的 安 草 测试 机 上 不 了 Google Play。 

真 没 想到 手机 抓 包 这 么 麻烦 ， 相 比 之 下 电脑 抓 包 实 在 太 方 便 了 ， 只 
要 闭 个 Wireshark 就 行 ， 分 分 钟 搞 定 。 那 有 没有 办 法 用 Wireshark 来 抓 手 
机 上 的 包 呢 ?这 个 问题 让 我 想起 了 大 学 寝室 的 网 络 拓 扑 ， 当 时 我 们 究 室 
四 个 人 只 共享 一 个 对 外 的 网 口 ， 所 以 就 在 我 的 电脑 上 装 了 两 个 网 卡 ， 网 
卡 1 对 外 ， 网 卡 2 和 室友 们 的 电脑 连 在 一 个 交换 机 上 ， 如 图 2 所 示 。 


交换 机 











我 的 电脑 小 徐 的 电脑 小 陈 的 电脑 小 顾 的 电脑 
图 2 
这 样 室友 们 的 对 外 流量 就 是 通过 我 的 “网 卡 2 网 卡 1” 出 去 了 ， 理 论 
上 只 要 在 我 的 网 卡 上 抓 包 ， 束 能 知道 哪 位 室友 在 和 女神 聊 QQ， 哪 位 室 
友 在 祝 楼 主 好 人 一 生平 安 了 “兄弟 们 饶 命 ， 我 就 说 说 而 已 ， 没 有 真 抓 
过 ) 。 假 如 把 我 家 的 网 络 拓扑 也 改 成 这 样 ， 让 手机 也 通过 我 的 电脑 上 
网 ， 不 就 可 以 用 Wireshark 抓 到 手机 连 WiFi 时 的 包 了 吗 ? 当前 我 家 的 网 
络 拓扑 如 图 3 所 示 ， 手 机 的 网 络 包 都 通过 无 线路 由 器 出 去 了 ， 我 得 改造 
一 下 ， 让 它们 走 一 台 已 经 淘汰 不 用 的 台式 机 。 





入 户 modem 


无 线路 由 器 


淘汰 的 台式 机 





有 线 连 接 
~ 一 一 一 无 线 连接 


iPhone 安 卓 
图 3 
线路 改造 只 花 了 几 分 钟 : 我 先 把 无 线路 由 器 撤 反 ， 再 把 入 户 modem 
直接 连 到 人 台式 机 的 网 卡 1 上 ， 这 样 台式 机 就 可 以 上 网 了 。 接 下 来 只 要 把 
台式 机 的 网 卡 2《〈 无 线 的 ) 设 为 热点 ， 就 能 供 手 机 上 网 了 。 网 络 拓扑 如 
图 4 所 示 。 












入 户 modem 


一 一 一 一 有 线 连接 
= 一 -~ 无 线 连 接 


图 4 
oo 点 ， 但 也 说 不 上 很 难 。 


”1. 执行 图 5 的 命令 ， 








:sers dministrator2netsh wlan start hostednetwork 


已 启动 革 载 网 络 。 


< 


oo 





图 5 
2. 把 台式 机 的 网 卡 1 共 享 给 无 线 网 络 ， 如 图 6 所 示 。 








Internet ] 庄 按 共享 
» 其 本 | » 本 erne » 
回 菜 这 持久 3 络 用 户 通 过 此 计算 机 的 Internet 连接 


家 庭 网 络 过 接 00 : 
无 线 了 网络 连 接 2 


图 于 证 其 仙 3 后 用 户 控 制 器 条 用 共事 和 Internet 库 


使 用 ICS (Internet ] 车 接 共 误 ) [设置 (6)... | (6) 





3. 此 时 控制 面板 中 应 该 可 以 看 到 4 个 连接 ， 如 图 7 所 示 。 
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DO" meinen | 
组 织 > ae 


| [ 啊 本 地 连接 Re 本 地 连接 2 
网 络 , 共享 的 网 络 电 绕 被 拔 出 
dS TAP-Windows Adapter V9 


Realtek RTL8168D/8111D 系列 .… 
无 线 网 络 连 接 无 线 网 络 连 接 2 


未 连接 wireless 
- 串 DW1501 Wireless-N WLAN Ha... 省 Microsoft Virtual WIFI Minipor... 








图 7 


4. 在 手机 上 扫 到 热点 ， 输 入 密码 就 连 上 了 ， 如 图 8 所 示 。 
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Cancel Add Network Manu..， Save 





Network SSID 


wireless 


Security WPA/WPA2 PSK 


12345678 


Advanced Options 


图 8 
5. 在 台式 机 上 打开 Wireshark， 从 Capture Interfaces 可 以 看 到 4 个 连 


接 ， 义 上 我 们 感 兴趣 的 无 线 网 络 束 可 以 了 ， 本 地 连接 没 必 要 抓 。 注 意 有 
些 老 版 本 的 Wireshark 是 抓 不 到 无 线 网 络 包 的 ， 你 也 许 需 要 升级 到 最 新 版 
本 。 




















| {Wiresharke Capture Interfaces Fe 区 习 
Device Description Pp Packets Packets/s 
加 饼 | 无 线 网 络 连接 2 Microso 代 fe80::74d3:70ae:dba5:55d6 0 0 
喇 本 地 连接 Realtek RTL8168D/8111D PCLE Gigabit Ethemet NIC fe80::9cd5:1f56:11cd:25f4 4 0 
问 羡 | 无 线 网 络 连接 。 Microsoft fe80::38f3:ecd7:8e:5b78 0 0 
回 成 | 本 地 连接 2 TAP-Windows Adapter V9 fe80::4d45:59a0:bl0e:961f 0 0 











Start Stop Qptions Close 








图 9 
以 上 步骤 仅 供 参考 ， 因 为 在 不 同 的 环境 中 ， 即 使 严格 遵循 这 些 步骤 
也 有 失败 的 可 能 ， 比 如 有 些 无 线 网 卡 天 生 就 不 文 持 当 热 点 。 我 还 遇 到 过 


一 个 问题 ， 就 是 在 第 4 步 时 手机 一 直 连 不 上 ， 抓 包 看 到 它 发 了 很 多 DHCP 
请 求 给 台式 机 ， 但 是 没有 得 到 回复 ， 如 图 10 所 示 。 








| No. Time Source Destination Protocol Info 
950 97.044089000 0.0.0.0 255.235.255.253 DHEP DHCP Discover - Transaction 
953 100.052233000 0.0.0.0 2 3922335 DHEP DHCP Discover - Transaction 
957 109.057178000 0.0.0.0 255.255.2355.2535 .DHEP DHCP Discover - Transaction 
1035 125.056014000 0.0.0.0 25552555255:253 “DP DHCP Discover - Transaction 
1055 157.064822000 0.0.0.0 255.255.255..255 DiCP DHCP Discover - Transaction 
1060 160.075296000 0.0.0.0 2335233233.235 DHEP DHCP Discover - Transaction 
* i 





HFrame 950: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0 
日 IEEherneeE Ti, Stre: d05df 3 9acf:88:30 (U0Ordfsqacf e830),. USE: THefT ertfitt fetef CfotteteEtt 
Destinations FF TE TFTFrF CFFf ff tftf:F ED 
四 Source: d0:df:9a:cf:88:30 (d0:df:9a:cf:88:30) 
Type: IP (0x0800) 


图 10 
为 了 市 省 时 间 ， 我 没有 去 研究 解决 DHCP 的 问题 ， 而 是 在 手机 上 人 
工 配置 了 IP。 如 果 你 比 我 还 懒 ， 甚 至 可 以 连 1、2、3 步 都 不 做 ，Google 
一 下 “无 线 网 卡 +WiFi 热 点 *"， 找 一 些 软件 来 自动 完成 这 些 步骤 。 不 过 这 
样 做 可 能 遇 到 流氓 软件 ， 安 全 性 不 能 保证 。 
这 次 网 络 改造 非常 值得 ， 因 为 从 此 家 里 每 个 手机 的 网 络 包 都 可 以 用 
Wireshark 抓 到 了 ， 使 我 更 有 动力 去 研究 手机 网 络 。 比 如 我 想 知 道 手 机 开 





机 后 的 第 一 个 网 络 动 作 是 什么 ， 抓 个 包 就 一 目 了 然 。 从 图 11 可 见 ， 它 先 
通过 DNS 碍 询 NTP 服 务 器 的 卫 地 址 ， 然 后 就 发 NTP 包 去 同步 时 间 了 。 这 
就 是 为 什么 手机 时 间 用 不 着 调整 ， 但 是 走 得 比 江诗丹顿 还 准 。 至 于 本 文 
开头 提 到 的 那个 耗 流量 App， 原 来 是 因为 它 不 停 地 刷 某 个 网 页 ， 估 计 是 
中 了 木马 ， 被 我 删 掉 了 。 


No. Time Source Destination 














Protocol Info 
4 0.086701000 Android publici.alidns.com DNS standard query Oxbbc7 A asia.pool.ntp.org 
5 0.095904000 publici.alidns. com Android DNS standard query response Oxbbc7 A 194.27.44.55 
6 0.100035000 Android asia.pool.ntp.org NTP NTP Version 3, client 
31 3.546978000 asia.pool.ntp.org Android NTP NTP Version 3, server 


图 11 


不 知道 为 什么 ， 有 de 
Loading《 见 图 1) 。 这 不 只 是 我 的 个 人 感受 ， 很 多 网 友 都 抱 仿 过 。 而 装 
在 同一 个 手机 上 的 微 信 ， 连 的 也 是 同一 个 WiFi， 却 没有 这 虽然 
这 个 问题 出 现 的 并 不 频繁 ， 但 假如 我 是 微 博 的 开发 人 员 ， 肯 定 要 把 原因 
找 出 来 。 


China Mobile 2:23 PM 





A 林 沛 满 。 CJ 





图 1 
当 我 的 手机 抓 包 环 境 搭 好 时 ， 第 一 个 想 解决 的 问题 就 是 这 个 。 我 随 
意 发 了 一 条 微 博 ， 虽 然 没 有 碰 到 卡 顿 ， 但 还 是 把 包 抓 下 来 了 。 开 头 几 个 
网 络 包 如 图 2 所 示 。 








No. Time Source Destination Protocol Info 
1 0.000000000 Android DNS_Server DNS standard query Ox917c A api.weibo.cn 
3 0.009664000 DNS_Sserver Android DNS standard query response Ox917c CNAME weibo. cn 
4 0.011417000 Android weibo. cn TCP 48658-80 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 : 
7 0.044534000 weibo.cn Android TCP 80-48658 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=( 
8 0.045467000 Android weibo. cn TCP 48658~80 [ACK] Seq=1 Ack=1 Win=14720 Len=0 
图 2 


我 又 及 了 一 条 测试 私信 ， 可 异 也 没有 卡 顿 。 开 头 几 个 网 络 包 如 图 3 
所 示 。 





No. Time Source Destination Protocol Info 
0.000000000 Android DNS_server DNS standard query 0x860b A ps.im.weibo. cn 


1 
2 0.009506000 DNS_Sserver Android DNS standard query response Ox860b A 180.149.134.252 
3 0.011703000 Android ps.im.weibo. cn TCP 42555-8080 [SYN] seq=0 Win=14600 Len=0 MSS=1460 S 
4 0.040482000 ps.im.weibo.cn Android TCP 8080-42555 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 
5 0.041463000 Android ps.im.weibo.cn TCP 42555-8080 [ACK] Seq=1 Ack=l Win=14720 Len=0 

图 3 


里 然 两 次 部 没有 重 现 问题 ， 但 是 从 网 络 包 可 见 ， 微 博 的 工作 方式 严 
重 依赖 DNS。 它 在 调用 任何 功能 之 前 都 要 先 癌 DNS 服务 器 得 询 ， 得 到 提 
供 该 功能 的 服务 器 中， 然后 再 建立 TCP 连 接 。 最 神奇 的 是 它 不 会 缓存 碍 
询 结果 ， 所 以 需要 频繁 地 重复 查询 DNS。 我 才 抓 了 两 分 钟 包 ， 竟 然 就 看 
到 了 上 百 个 查询 ， 这 会 不 会 融 是 微 博 卡 顿 的 原因 呢 ? 我 又 抓 了 一 个 发 微 
信 的 包 作 对 比 ， 如 图 4 所 示 。 











No. Time Source Destination Protocol Info 
1 0.000000000 Android 3 了 4. 7-525J37 TCP 37613~80 [SYN] Seq=0 Win=14000 Len=0 MI! 
2 0.033016000 L417.52.137 Android TCP 80-37613 [SYN, ACK] Seq=0 Ack=1 Win=14: 
3 0.034825000 Android 17 523137 TCP 37613-80 [ACK] Seq=1 Ack=1 Win=1792000 
图 4 








果然 ， 微 信和 客户 端 直接 就 和 一 个 IP 地 址 建立 了 连接 。 不 管 这 个 IP 是 
写 在 配置 文件 中 的 ， 还 是 之 前 就 存在 手机 的 缓存 里 的 ， 这 至 少 说 明了 微 
信 不 像 微 博 那样 依赖 DNS。 

为 了 进一步 验证 这 个 猜测 ， 我 故意 把 手机 上 的 DNS 服务 器 配 成 一 个 
不 存在 的 地 址 。 不 出 所 料 ， 微 信 还 是 能 照常 工作 ， 但 微 博 就 在 也 刷 不 出 
来 了 。 之 前 我 手机 上 配 的 DNS 服务 器 位 于 美国 ， 可 能 有 时 候 路 国 连接 不 
稳定 ， 所 以 导致 了 微 博 的 卡 顿 现象 。 考 虑 到 这 一 点 ， 我 党 试 配 了 一 个 国 
内 的 DNS《〈 见 图 5) ， 果 然 从 此 再 也 没 卡 过 了 ， 刷 起 来 卉 常 流畅 。 
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Network Prefix Length 


DNS 


图 5 

当 你 看 到 这 篇 文章 的 时 候 ， 也 许 这 个 问题 已 经 被 新 浪 解 决 了 ， 因 为 
我 已 经 同 微 博 的 技术 人 员 反 人 馈 过 (或 者 他 们 早已 经 知道 ) 。 相 信和 解决 起 
来 也 不 复杂 ， 只 要 像 微 信 一 样 缓存 了 就 可 以 了 。 据 我 所 知 ， 苹 果 的 App 
Store 和 小 米 电视 也 遭遇 过 DNS 导致 的 性 能 问题 ， 所 以 相信 还 有 很 多 设备 
或 者 程序 可 以 利用 Wireshark 来 优化 ， 只 要 把 使 用 过 程 的 包 都 抓 下 来 ， 说 
不 定 就 能 发 现 值得 改进 的 地 方 。 

最 后 再 补充 一 个 小 发 现 。 我 发 的 微 博 内 容 是 “capture test, will 
delete it soon.”， 分 享 范 围 设 成 * 仅 自己 可 见 ”。 没 想到 在 Wireshark 上 直接 
就 看 到 了 明文 ( 见 图 6 底部 ) ， 发 私信 和 就 没有 这 个 问题 。 因 此 我 们 连 公 
共 WiFi 发 微 博 的 时 候 ， 还 是 要 小 心 一 点 。 不 要 以 为 设 成 “分 组 可 见 ? 或 





者 “ 仅 自 己 可 见 ” 就 够 私密 了 ， 其 实在 Wireshark 上 都 能 看 到 。 





Time 
36 0.097649000 
37 0.099154000 
38 0.099310000 
39 0.100289000 
40 0.100330000 


站 


Source Destination 
weibo. cn Android 
Android weibo. cn 
Android weibo. cn 
weibo. cn Android 
weibo. cn Android 


Protocol Info 

TCP 80-48658 [ACK] Seq=1 Ack=1538 Win=19968 Len=0 
TCP [TCP segment of a reassembled PDU] 

HTTP POST /2/statuses/send?uicode=10000017&c=android 
TCP 80-48658 [ACK] Seq=1 Ack=1703 Win=21248 Len=0 
TCP 80-48658 [ACK] Seq=1 Ack=1913 Win=22656 Len=0 
用 





”日 Line-based text data: text/plain 
[Capture test\337\274\214w11| delete 1t_soon. 


图 6 


寻找 HttpDNS 


这 几 年 互联 网 行业 有 多 火 ? 假如 有 块 陨石 掉 进 创业 园区 ， 说 不 定 能 
硬 到 两 位 互联 网 架构 师 ;， 要 是 没 学 会 几 句 互联 网 黑 话 ， 你 都 不 好 意思 说 
自己 是 搞 开 的 。 不 久 前 就 有 位 架构 师 在 技术 群 里 讨论 鹅 厂 〈 黑 话 ， 即 腾 
讯 公司 ) 的 HttpDNS， 令 我 自 怖 形 秘 ， 因 为 这 个 词 我 从 来 没有 听 说 过 。 

为 了 掩饰 自己 的 孤 陋 寡 逆 ， 我 悄悄 做 了 点 功 诬 ， 发 现 这 技术 还 挺 有 
趣 的 。 而 要 学 习 它 ， 就 得 从 最 传统 的 DNS 开始 说 起 。 

我 们 都 知道 上 网 的 时 候 需 要 先 把 域名 解析 成 IP 地 址 ， 比 如 我 在 浏览 
器 中 输入 www.qq.com 再 按 回 车 ， 就 会 通过 DNS 查 询 到 该 域名 所 对 应 的 
IP， 然 后 再 与 之 建立 连接 。 但 是 很 多 人 并 不 知道 ，DNS 的 解析 结果 是 很 
智能 的 。 对 于 同一 个 域名 ， 上 海 电 信 的 用 户 一 般 会 解析 到 属于 上 海 电 信 
的 JP 地 址 ， 北 京 联通 的 用 户 一 般 会 解析 到 属于 北京 联通 的 IP 地 址 。 请 看 
下 面 两 个 关于 www.qq.com 的 不 同 解 析 结 

上 海 电信 用 户 解 析 到 了 101.226.129.158〈 见 图 1) 。 经 查证 ， 该 IP 属 
于 上 海 电 信和 凹 。 




















Filter: [>| Expression.. Clear Apply Save 
No. Time e Destination Protocol Info 
| 1 0.000000000 Dianxin_cClient Dianxin_Local_DNS DNS standard query Ox0002 A www.qq.com 
2 0.004274000 Dianxin_Local_DNS Dianxin_Client DNS standard query response Ox0002 A 101.226.129.158 
图 1 


北京 联通 用 户 解析 到 了 61.135.157.156 〈 见 图 2) 。 经 查证 ， 该 IP 属 
于 北京 联通 。 





Filter [| Erpression.. Clear Apply Save 
No. Time Source D n Protocol Info 
1 0.000000000 Liantong_Client Liantong_Local_DNS DNS standard query Ox0002 A www.qq. Com 
2 0.033494000 Liantong_Local_DNS Liantong_Client DNS standard query response 0x0002 A 61.135.157.156 


图 2 
这 个 智能 技术 是 怎样 实现 的 呢 ? 原来 DNS 文 持 GSLB (Global Server 


Load Balance， 全 局 负载 均衡 ) ， 能 根据 DNS 请 求 所 包含 的 源 地 址 返回 
最 佳 结 末 ， 从 而 匹配 同 地 区 、 同 运营 商 的 耳 ， 使 用 户 体验 到 最 好 的 性 
能 。 图 3 演示 了 这 个 解析 过 程 。 
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图 3 

不 过 这 个 机 制 并 非 完美 ， 比 如 当 用 户 自 己 配 错 DNS 服 务 器 的 时 候 就 
可 能 出 问题 。 图 3 的 腾讯 GSLB 服 务 器 其 实 并 不 是 通过 用 户 的 地 址 来 判断 
该 返回 什么 卫 的 ， 而 是 根据 DNS 服务 器 的 地 址 来 判断 的 。 假 如 上 海 电 信 
用 户 偏 偏 要 配 一 个 北京 联通 的 DNS 地 址 ， 那 它 发 送 DNS 查 询 时 ， 就 是 由 
北京 联通 转 给 GSLB 的 ， 因 此 会 解析 到 属于 北京 联通 的 IP 地 址 。 由 于 中 
国 的 跨 运 营 商 网 络 一 向 是 瓶颈 ， 所 以 用 户 体验 会 很 糟糕 。 还 有 些 用 户 配 
的 是 在 美国 的 DNS 服务 器 8.8.8.8， 那 就 可 能 解析 到 一 个 位 于 美国 的 卫 地 
址 (启用 了 谷歌 扩展 协议 的 客户 端 除外 ) ， 网 速 束 更 差 了 。 根 据 公 众 
号 “ 鹅 厂 网 事 ” 的 说 法 ， 他 们 遭遇 的 GSLB 问 题 还 有 很 多 ， 比 如 劫持 什么 
的 5 水文 庙 不 一 一 壮丁 

那 护 三 的 解决 方式 是 什么 昵 ?” 就 是 本 文 开 头 提 到 的 HttpDNS。 它 允 
许 手 机 上 的 App 直 接 查 询 腾讯 自家 的 HttpDNS 服 务 器 ， 因 此 能 根据 用 户 











的 地 址 来 判断 应 该 返回 什么 IP， 从 而 跳 过 传统 DNS 的 影响 。 换 句 话 说 ， 
就 是 腾讯 觉得 用 传统 DNS 不 靠 谱 ， 所 以 目 己 做 了 一 套 解 析 方 式 ， 只 不 过 
这 人 套 方 式 是 走 HTTP 协 议 的 ， 图 4 演示 了 这 个 过 程 。 





上 海 电信 用 户 


HttpDNS 服 务 器 





北京 联通 用 户 
图 4 

从 原理 上 看 ，HttpDNS 是 科学 的 ， 不 过 得 多 花 些 钱 去 部 署 。 根 
据 “ 鹅 三 网 事 ” 的 宣传 ， 似 乎 在 内 部 已 经 推广 了 : 

“HttpDNS 己 在 腾讯 内 部 接 入 了 多 个 业务 ， 禾 盖 数 亿 用 户 ， 并 已 持 
续 稳 定 运行 超过 一 年 时 间 。 而 接 入 了 HttpDNS 的 业务 在 用 户 访问 体验 方 
面 都 有 了 非常 大 的 提升 .…… 国 内 最 大 的 public DNS 服务 商 114DNS 在 受 
到 腾讯 DNS 的 启发 下 ， 也 推出 了 HttpDNS 服 务 ..…....” 

这 个 宣传 昕 上 去 非常 吸引 人 。 去 年 发 生 过 一 次 全 国 性 的 DNS 竣 疾 ， 





当时 鹅 三 的 几 个 应 用 (比如 QQ 和 微 信 )〉 都 能 正常 使 用 ， 似 乎 就 是 一 个 
有 力 的 佐证 。 连 鹅 三 的 竞争 对 手 似乎 也 加 入 了 宣传 ， 比 如 淘宝 的 官方 微 
博 发 过 一 条 消息 ， 称 “手机 淘宝 使 用 专 为 移动 设计 的 方案 ”不 会 受到 DNS 
次 痪 的 影响 。 当 时 也 有 圈 内 牛人 出 来 解释 ， 说 这 意味 着 手 淘 也 开始 用 上 
HttpDNS 了 。 总 而 言 之 ， 如 果 你 对 技术 圈 的 八卦 消息 感 兴趣 ， 一 定 会 觉 
得 HttpDNS 已 经 快 颠覆 DNS 了 。 

事实 真 的 如 此 吗 ? 我 一 直 有 些 怀疑 ， 理 由 如 下 。 

.电脑 上 很 多 应 用 程序 也 依赖 DNS 解析 ， 而 且 在 电脑 上 很 容易 配 错 
DNS 服 务 器 ， 理 论 上 出 问题 的 概率 更 大 ， 为 什么 束 不 部 车 HttpDNS? 而 
手机 上 的 DNS 地 址 一 般 是 运营 商 自 动 分 配 的 ， 出 问题 的 概率 小 ， 为 什么 











反而 要 部 普 ? 

即便 运营 商 分 配 的 DNS 有 问题 ， 那 也 可 以 通过 行政 手段 来 解决 ， 
何必 要 为 此 大 动 干戈 呢 ? 

国外 的 互联 网 公司 也 会 过 到 这 类 问题 ， 为 什么 它们 束 没 有 采用 
HttpDNS? 


.传统 DNS 基于 UDP 碍 询 的 速度 很 快 ， 而 HttpDNS 肯 定 是 基于 TCP 
的 ， 那 还 会 浪费 3 次 握手 和 4 次 挥手 的 时 间 。 

HttpDNS 如 有 果 不 加 密 ， 那 也 很 容易 被 劫持 ， 如 果 加 密 了 ， 解 析 效 率 
又 会 大 受 影响 。 

总 之 有 太 多 难以 解释 的 疑问 了 ， 我 越 琢磨 就 越 想 看 看 HttpDNS 的 访 
山 真面目 。 为 了 解 开 这 个 谜 题 ， 我 在 搭 好 手机 抓 包 环 境 之 后 ， 束 设计 了 
一 系列 实验 来 寻找 这 个 传说 中 的 新 技术 。 

实验 1 

1. 启动 Wireshark 抓 包 。 

2. 登录 手机 淘宝 。 

3. 停止 抓 包 并 分 析 。 

Wireshark 和 截屏 见 几 5。 这 个 结果 令 我 大 失 所 望 ， 原 来 手 淘 老 老实 实 








地 用 传统 DNS 查询 到 了 服务 器 d.taobaocdn.com 的 IP 地 址 ， 然 后 就 三 次 握 
手 了 。 也 就 是 说 ， 它 并 没有 用 到 HttpDNS 。 


o. Time Source Destination Protocol Info 

1 0.000000000 Android DNS DNS standard query Ox6123 A d.taobaocdn. com 

2 0.009048000 DNS Android DNS standard query response 0x6123 CNAME d.taobaocdn. com. 
3 0.010750000 Android d.taobaocdn. com TCP 45134~80 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PEF 
4 0.016174000 d.taobaocdn. com Android TCP 80-45134 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=14 
5 0.017097000 Android d.taobaocdn. com TCP 45134~80 [ACK] Seq=1 Ack=1 Win=14656 Len=0 TSval=1205 


图 5 

那 淘 宝 官方 微 博 宣称 的 “ 专 为 移动 设计 的 方案 ”是 什么 呢 ? 我 又 做 了 
个 实验 。 

实验 2 

1. 登录 手机 淘宝 。 

2. 然后 故意 把 手机 上 的 DNS 服务 器 改 错 ， 发 现 手 淘 还 能 用 。 

3. 退出 手 淘 ， 再 次 登录 ， 就 再 也 登 不 上 去 了 。 

可 见 这 所 谓 的 方案 只 不 过 是 在 登录 之 后 缓存 了 而 已 ， 并 不 是 用 
HttpDNS 取 代 DNS。 既 然 手 淘 不 行 ， 我 决定 在 手机 上 装 个 鹅 三 的 QQ 试 
试 。 这 一 次 我 故意 从 一 开始 不配 错 DNS 。 

实验 3 

1. 在 手机 上 配 个 无 效 的 DNS， 然 后 开始 Wireshark 抓 包 。 

登录 手机 QQ。 
停止 抓 包 并 分 析 。 

Wireshark 和 截图 如 图 6 所 示 。 手 机 发 了 几 个 传统 的 DNS 碍 询 都 没有 得 
到 响应 ， 然 后 竟然 就 和 IP 地 址 113.108.90.53 三 次 握手 了 。 这 个 IP 从 何 而 
来 ? 应 该 就 是 来 自 HttpDNST 了 吧 ? 然而 在 Wireshark 中 用 尽 各 种 Filter 和 
Find 都 找 不 到 相应 的 包 。 难 不 成 这 个 IP 是 安装 QQ 时 就 存在 配置 文件 中 
的 ? 我 从 IP 库 中 查 到 它 位 于 1500 公 里 外 的 深圳 市 ， 应 该 不 会 是 高 度 智能 
的 HttpDNS 解 析出 来 的 。 




















No. Time Source Destination Protocol Info 

231 41.944338000 Android Wrong_DNS DNS standard query Oxf3cf A msfwifi.3g.qq.com 

232 41.944542000 Android Wrong_DNS DNS standard query Oxe9df A configsvr.msf.39.99q. com 

233 42.463699000 Android Wrong_DNS DNS standard query Ox3e39 A monitor.uu.qq.com 

237 45.945841000 Android wrong_DNS DNS standard query Oxbb54 A strategy.beacon. qq. COm 

238 46.943161000 Android wrong_DNS DNS standard query Oxf403 A monitor.uu.qq.com 

239 46.969910000 Android 113.108.90.53 TCP 34777~8080 [SYN] seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 
| 240 47.010944000 113.108.90.53 Android TCP 8080-34777 [SYN, ACK] Seq=0 Ack=1 Win=5400 Len=0 MSS=1350 $s, 

241 47.012451000 Android 113.108.90.53 TCP 34777~8080 [ACK] Seq=1 Ack=1 Win=14720 Len=0 


图 6 

三 个 实验 结果 都 和 预想 的 不 同 ， 真 令 人 心情 复杂 ， 难 道 技 术 圈 的 传 
闻 并 不 可 靠 ? 反正 时 间 都 花 了 这 么 多 了 ， 我 索性 再 做 一 个 实验 ， 彻 底 搞 
清楚 QQ 的 工作 方式 。 

实验 4 

1. 在 手机 上 配 一 个 正确 的 DNS， 然 后 开始 Wireshark 抓 包 。 

2. 登录 手机 QQ。 

3. 停止 抓 包 再 分 析 。 

Wireshark 截 图 如 图 7 所 示 。QQ 老 老实 实地 用 传统 DNS 人 查 到 IP， 然 后 
就 三 次 握手 了 。 可 见 它 首选 的 束 是 传统 DNS， 只 有 当 DNS 查 询 失 败 ， 它 
才 直 接 用 (可 能 存在 配置 文件 里 的 ) IP 来 登录 ， 根 本 没有 用 到 

















HttpDNS. 

No, Time Source Destination Protocol Info 
10 0.978862000 Android DNS DNS standard query Oxf044 A msfwifi.3g.qq.com 
11 0.989012000 DNS Android DNS standard query response Oxf044 A 113.108.16. 66 
12 0.990810000 Android msfwifi.3g.qq.com TCP 40188-8080 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 
26 1.030616000 msfwifi.3g.qq.com Android TCP 8080-~40188 [SYN, ACK] Seq=0 Ack=1 Win=5400 Len=( 
27 1.031460000 Android msfwifi.3g.qq.com TCP 40188-8080 [ACK] Seq=1 Ack=1 Win=14720 Len=0 


图 7 

一 系列 实验 做 下 来 ， 我 竟然 没有 找到 传说 中 的 HttpDNS。 鹅 三 宣 传 
的 “多 个 业务 ”究竟 指 的 是 哪些 ， 我 也 不 得 而 知 。 不 过 既然 连 QQ 和 手 淘 
都 没 在 用 ， 我 怀疑 世界 上 本 来 就 没 多 少 知名 App 在 用 它 。 即 便 有 ， 我 也 
没有 动力 再 去 寻找 了 。 当 然 做 了 这 些 实验 也 不 是 一 无 所 获 ， 至 少 理 清楚 
了 几 个 知名 App 在 域名 解析 上 的 行为 差异 。 

.新浪 微 博 : 一旦 出 现 DNS 问 题 就 不 能 用 ， 无 论 是 否 已 经 登录 ， 因 
为 它 不 缓存 IP。 详 细 实 验 过 程 请 看 前 一 篇 。 

:手机 淘宝 : 一 旦 出 现 DNS 问 题 就 无 法 登录 ， 但 是 登录 后 再 出 DNS 
问题 就 不 怕 了， 因为 它 有 绥 存 IP。 

手机 QQ: 出 现 DNS 问 题 时 也 能 用 ， 因 为 它 可 以 直接 用 (可 能 存在 
配置 文件 里 的 ) IP， 因 此 受 DNS 竣 痪 的 影响 最 小 。 

注意 : 我 只 是 描述 了 当前 观察 到 的 现象 ， 并 不 是 说 某 个 App 比 其 他 的 更 先进 。 而 且 互 联网 













































































界 变化 很 快 ， 说 不 定 等 你 看 到 这 篇 文章 时 ， 这 些 App 的 行为 又 有 所 不 同 ， 甚 至 真 的 用 上 HttpDNS 
了 ， 到 时 候 抓 包 才 知 道 。 

这 件 事 也 促使 我 重新 审视 技术 疾 的 信息 传播 。 有 段子 说 , “美国 研 
完 机 构 发 现 ， 人 们 很 容易 对 美国 研究 机 构 发 现 ' 开 头 的 报道 信 以 为 
真 。” 同 样 地 ， 当 IT 大 三 慷慨 地 分 盏 一 项 技术 时 ， 当 较 内 大 牛 热情 地 跟 
着 传播 时 ， 我 们 融会 本 能 地 觉得 高 大 上 起 来 。 而 真实 情况 如 何 ， 却 只 有 
自己 做 实验 才 知 道 。 小 马 过 河 ， 方 知 深浅 。 

















作为 中 国 网 民 ， 我 们 享有 学 习 网 络 知 识 的 天 然 优 势 ， 这 是 很 多 老外 
一 辈子 都 不 敢 和 奢望 的 。 还 记得 刚 学 会 上 网 的 时 候 ， 某 知名 搜索 网 站 突然 
就 连 不 上 了 ， 有 位 学 长 说 这 是 域名 被 封 ， 直 接连 卫 就 可 以 了 ， 还 帮 有 我 修 
改 了 hosts 文 件 。 于 是 我 沿 着 这 个 方向 研究 ， 很 快 就 理解 了 DNS 协议 。 在 
实践 中 学 到 的 本 领 ， 比 捧 着 课本 背诵 的 不 知道 高 到 哪里 去 。 

又 过 了 一 阵 ， 竟 然 连 IP 都 连 不 上 了 。 我 在 探索 过 程 中 ， 又 学 会 了 
HTTP 代 理 和 VPN 等 科学 上 网 技术 。 就 这 样 ， 十 几 年 下 来 身 经 百 战 ， 不 
知 不 觉 中 掌握 了 很 多 网 络 技 术 ， 每 天 都 能 到 外 网 和 同行 们 谈笑风生 。 现 
在 回忆 起 来 ， 我 的 知识 真 没 多 少 是 刻意 去 学 的 ， 而 是 在 和 网 络 问 题 斗 争 
时 被 动 学 会 的 。 被 上 讶 和 久 了 还 得 了 斯 德 哥 尔 摩 综 合 症 ， 去 年 到 国外 出 差 了 
一 个 月 ， 便 觉得 食 不 知味 ， 因 为 根本 找 不 到 学 习 的 机 会 。 回 到 国内 赶紧 
打开 浏览 器 ，Duang 一 一 立即 弹出 运营 商 推送 的 广告 。 还 是 那个 熟悉 的 
味道 ， 回 家 的 温馨 顿时 涌 上 心头 。 

本 文 要 讲述 的 也 是 一 个 类 有 中 国 特色 的 网 络 技 术 ， 其 实 很 多 人 都 遇 
到 过 ， 但 没有 去 深究 。 最 早 向 我 反馈 的 是 一 位 细心 的 网 友 ， 他 在 打开 
www.17g.com 这 个 游戏 网 站 时 ， 有 一 定 概率 会 加 载 出 其 他 网 站 的 游戏 ， 
比如 xunlei 的 。 他 觉得 很 好 奇 ， 便 采取 了 一 些 措施 来 排 碍 。 

1. 一 开始 怀疑 是 电脑 中 毒 ， 于 是 在 同 网 络 下 的 其 他 电脑 上 测试 ， 
症状 还 是 一 样 。 

2. 其 他 地 区 的 网 友 (包括 我 ) 打开 这 个 网 站 时 没有 发 现 相同 问 























3. 他 怀疑 是 当地 运营 两 〈( 哪 家 运营 丙 我 就 不 说 了 ) 搞 的 欣 ， 于 是 


换 了 个 宽带 ， 果 然 就 没 问 题 了 。 

这 位 网 友 很 生气 ， 想 知道 运营 商 究竟 对 他 的 网 络 做 了 什么 手脚 ， 所 
以 抓 了 个 出 问题 时 的 包 来 找 我 。 我 刚 开始 以 为 很 简单 肯定 是 运营 商 的 
DNS 动 持 ， 即 故意 在 收 到 DNS 查 询 时 回应 一 个 假 的 IP 地 址 ， 从 而 导致 客 
户 端 加 载 错误 的 广告 页 面 。 于 是 我 打开 网 络 包 ， 用 dns 作 了 过 滤 ， 发 现 
www.17g.com 被 解析 到 了 IP 地 址 123.125.29.243〈 它 还 有 一 个 别名 叫 
w3.dpool.sina.com.cn， 见 图 1) 。 可 是 经 过 进一步 测试 验证 ， 发 现 这 个 IP 
地 址 竟然 是 对 的 ， 并 没有 被 支持 。 




















Fiter dns -| Expression... Clear Apply Save 
No Time Source Destination Protocol Info 
1 0.000000000 Client DNS_Server DNS standard query Oxcdd8 A www.179. Com 
2 0.001818000 DNS_server Client DNS standard query response Oxcdd8 CNAME w3.dpool.sina.com.cn A 123.125.29.243 


图 1 
既然 不 是 DNS 劫持 ， 那 又 是 什么 原因 导致 的 呢 ? 可 惜 这 位 网 友 抓 包 
的 时 候 电 脑 上 开 了 太 多 应 用 ， 所 以 干扰 包 很 多 ， 无 法 采用 暴力 方式 来 分 
We 
用 “ip.addr eq 123.125.29.243” 过 渡 则 得 到 图 2 的 结果 ， 似 乎 平淡 无 奇 ， 
是 显示 有 些 包 乱 序 了 ， 但 不 知道 这 意味 着 什么 。 后 来 我 才 知 道 省 这 就 是 线 
索 之 一 ， 有 具体 原因 后 面 会 讲 到 。 

















Fiter | ip.addr eq 123.125.29.243 [>| Expression.. Clear Apply Save 

No, Time Source Destination Protocol jnfo 
3 2.466565000 Client w3. dpoo1.sina. com. cn TCP 58578-~80 [SYN] seq=0 Win=8192 Len=0 MSS=1460 WS= 
4 2.486628000 w3.dpool.sina.com.cn Client TCP 80-58578 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 | 
5 2.486716000 Client w3. dpoo1.sina. com. cn TCP 58578-~80 [ACK] Seq=1 Ack=l Win=65700 Len=0 
6 2.487789000 Client w3. dpoo1. sina. Com. cn TCP [TCP segment of a reassembled PDU] 
7 2.487807000 Client w3. dpoo1.sina.com.cn HTTP GET /game?game_id=1 HTTP/1.1 
8 2.491232000 w3.dpoo1.sina. com.cn Client TCP 80-~58578 [ACK] Seq=1 Ack=1461 Win=2102400 Len=0 
9 2.491663000 w3.dpool.sina.com.cn Client TCP 80-~58578 [PSH, ACK] Seq=1 Ack=1461 Win=2102400 L 
10 2.492354000 client w3. dpoo1.sina. com.cn TCP 58578-80 [FIN, ACK] Seq=1595 Ack=558 Win=65140 L 
11 2.507937000 w3.dpool.sina.com.cn Client TCP 80-58578 [ACK] Seq=1 Ack=1595 Win=17536 Len=0 

12 2.508130000 Ww3.dpool.sina.com.cn Client TCP 80-58578 [ACK] Seq=1 Ack=l Win=14720 Len=0 SLE=1 
13 2.508153000 Client w3. dpoo1. sina. com. cn TCP [TCP Dup ACK 10#1] 58578-80 [ACK] Seq=1596 Ack=5 
6: 23:7304D2000 Wa dood Oh eo0 a Ci Tcp [To Son nor CapEUFedT| 80-58578 [Ac 
27 2.739403000 w3.dpoo1.sina. com. cn Client TCP 80-~58578 [FIN, ACK] seq=4381 Ack=1595 Win=17536 
28 2.739439000 Client w3. dpoo1.sina. com.cn TCP [TCP Dup ACK 10#2] 58578-80 [ACK] Seq=1596 Ack=5 
29 2.739474000 client w3. dpoo1.sina. com. cn TCP [TCP Dup ACK 10#3] 58578-80 [ACK] Seq=1596 Ack=5 
30 2.739608000 w3.dpool.sina.com.cn Client TCP [TCP Out-of-order] [TCP segment of a reassembled 
31 2.739637000 Client w3. dpoo1.sina. com. cn TCP TCP ACKed unseen segment] 58578-~80 [RST, ACK] S 
32 2.739970000 w3.dpool.sina.com.cn Client TCP [TCP segment of a reassembled 


图 2 
由 于 这 是 我 第 一 次 分 析 动 持 包 ， 所 以 不 得 要 领 ， 当 上 晚 分 析 到 凌晨 都 
没有 弄 明 白 。 第 二 天 早上 只 好 到 技术 群 求援 了 ， 一 位 在 运营 商工 作 的 朋 


友 给 我 科普 J 了 HTTP 劫持 的 几 种 方式 。 其 中 有 一 种 引起 了 我 的 注意 ， 其 
大 概 工 作 方 式 如 图 3 所 示 ， 实 线 箭头 表示 正 币 的 网 络 包 ， 虚 线 箭头 表示 
运营 商 做 的 手脚 。 
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图 3 

注意 : 这 只 是 简单 的 示意 图 ， 不 完全 等 同 于 真实 过 程 。 

在 正常 情况 下 ， 用 户 发 出 的 HTTP 请 求 ( 即 图 中 的 @) 经 过 层 层 路 
由 才能 到 达 真 实 的 Web 服 务 器 ， 然 后 真实 的 HTTP 啊 应 〈 即 图 中 的 @) 
又 经 过 层 层 路 由 才能 回 到 用 户 病 。 而 在 做 了 手脚 的 网 络 中 ， 运 营 商 可 以 
在 路 由 右上 复制 HITP 请 求 ， 再 交 给 假 的 web 服务 器 。 然 后 赶 在 真实 的 
HTTP 响 应 之 前 ， 把 假 的 HITP 响 应 《〈 即 图 中 的 包 ) 送 达 用 户 。 这 个 抢先 
应 答 会 导致 用 户 在 收 到 真实 的 HTTP 响 应 时 ， 以 为 是 无 效 包 而 丢弃 。 

根据 这 个 工作 原理 ， 我 们 能 否 推 测 出 假 的 HTTP 啊 应 有 什么 特征 
呢 ? 如 果 能 ， 那 就 能 据 此 过 滤 出 关键 包 了 。 我 首先 考虑 到 的 是 网 络 层 的 
特征 : 因为 假 Web 服 务 器 是 抢先 应 答 的 ， 所 以 它 发 出 的 包 到 达 用 户 时 ， 
TIL (Time to Live) 可 能 和 真实 的 包 不 一 样 。 那 要 怎么 知道 真实 的 TTL 
应 该 是 多 少 呢 ? 考虑 到 3 次 握手 发 生 在 HITP 劫 持 之 前 ， 所 以 我 们 可 以 假 
定 参与 3 次 握手 的 那 台 服 务 器 是 真 的 ， 从 图 4 可 见 其 TTL 为 54。 






































Filter: | ip.addr eq 123,125.29.243 7| Expression... Clear Apply Save 





No, Time Source Destination Protocol Info 
3 2.466565000 Client w3. dpoo1.sina. com. cn TCP 58578-80 [SYN] seq=0 Win=8192 Len=0 
4 2.486628000 w3.dpool.sina.com.cn Client TCP 80-~58578 [SYN, ACK] Seq=0 Ack=1 Win=: 
5 2.486716000 Client w3. dpoo1. sina. com. cn TCP 58578-80 [ACK] Seq=1 Ack=1 Win=65700 
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Fragment offset: 0 


Protocol: TCP (6) 








图 4 
接 下 来 就 要 动手 过 滤 出 假 的 包 了 。 根 据 其 源 地 址 同样 为 
123.125.29.243， 但 TIL 不 等 于 54 的 特征 ， 我 用 “(ip.srceq 123.125.29.243) 
(ip.ttl==54)” 过 滤 ， 得 到 图 5 的 两 个 包 ， 即 8 号 包 和 9 写 包 。 看 看 厂 
下 角 显 示 了 什么 信息 ? 这 不 正 是 我 要 寻找 的 假 页 


面 “src=http://jump.niu.xunlei.com:8080/6zma2a” 吗 ? 














Filter: | (ip.src eq 123.125.29.243) &8 !(ip.tt! == 54) [| Expression... Clear” Apply ‘Save 


INo. Time Source Destination Protocol jlnfo 

8 2.491232000 w3.dpool.sina.com.cn Client TCP 80-58578 [ACK] Seq=1 Ack=l461 Win=2102400 Len=0 
9 2.491663000 w3.dpool.sina.com.cn Client TCP 80-58578 [PSH, ACK] Seq=1 Ack=1461 Win=2102400 
[ 





站 只 

0000 94 de 80 ff 62b33c8c 40 08 28 b2 08 00 45 00 “De re 
0010 02 55 10 03 40 00 4b 06 79 d2 7b 7d ld f3 0a 00 .U..@.K y。 

0020 00 5e 00 50 e4 d2 b6 8f aa 32 54 f6 f2 6a 50 18 。 A 2T 


Es | 
0030 40 29 本 00 00 48 54 54 50 2f 31 2e 31 20 32 0) 全. .HT TP/1i.i 2 
0040 30 30 20 4f 4b 0d 0a 53 65 72 76 65 72 3a 20 41 00 OK..S erver: A 
0050 70 61 63 68 65 0d 0a 43 6f 6e 6e 65 63 74 69 6f pache..C onnectio 
0060 6e 3a 20 63 6c 6f 73 65 0d 0a 43 6f 6e 74 65 6e n: close ..Conten 
0070 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 68 74 6d t- e: text/htm 
0080 6c 3b 20 63 68 61 72 73 65 74 3d 67 62 6b 0d 0a 1; ars et=gbk.. 
0090 53 65 74 2d 43 6f 6f 6b 69 65 3a 20 61 70 78 €¢ set-Cook ie: apx] 
00a0 70 3d 31 3b 20 65 78 70 69 72 65 73 3d 57 65 64 p=1; exp ires=Wed 
00b0 2c 20 31 38 2d 4d 61 72 2d 32 30 31 35 20 30 31 ， 18-Mar -2015 01 
00c0 3a 31 39 3a 34 33 20 47 4d 54 0d 0a 43 6f 6e 74 :19:43 G MT. .Cont 
00d0 65 6e 74 2d 4¢c 65 6e 67 74 68 3a 20 33 38 34 0d ent-Le th: 384. 
00e0 0O0a 0d 0a 3c 68 74 6d6c 3e 3c 68 65 61 64 3e 3c ...<html ><head>< 
00f0 6d 65 74 61 20 68 74 74 70 2d 65 71 75 69 76 3d meta htt p-equiv= 
0100 22 43 6f 6e 74 65 6e 74 2d 54 79 70 65 22 20 63 "Content -Type” Cc 
0110 6f 6e 74 65 6e 74 3d 22 74 65 78 74 2f 68 74 6d ontent="” Text/htm 
0120 6c 3b 20 63 68 61 72 73 65 74 3d 67 62 6b 22 3e 1; chars et=gbk"> 
0130 3c 6d 65 74 61 20 68 74 74 70 2d 65 71 75 69 76 <meta ht tp-equiv 
0140 3d 27 70 72 61 67 6d 61 27 20 63 6f 6e 74 65 6e = "pragma ”conten 
0150 74 3d 27 6e 6f 2d 63 61 63 68 65 27 3e 3c 2f 68 ='no-ca che'></h 
0160 65 61 64 3e 35 62 6f 64 79 20 73 74 79 6c 65 3d ead><bod y style= 
0170 22 6f 76 65 72 66 6c 6f 77 3a 68 69 64 64 65 6e "overflo w:hidden 


0180 22 20 74 6f 70 6d 61 72 67 69 6e 3d 22 30 22 20 " topmar gin="0" 

0190 6c 65 66 74 6d 61 72 67 69 6e 3d 22 30 22 20 72 ightmarg n="0" r 
0la0 69 67 68 74 6d 61 72 67 69 6e 3d 22 30 22 3e 3c htmarg in="0">< 
01b0 69 66 72 61 6d 65 20 66 72 61 6d 65 62 6f 72 64 re ramebord 
olc0 65 72 3d 22 30 22 20 6d 61 72 67 69 6e 68 65 69 ="0" m arginhei 


01d0 67 68 74 3d 22 30 22 20 6d 61 72 67 69 6e 77 69 ght="0" marginwi 
Ole0 64 74 68 3d 22 30 22 20 62 6f 72 64 65 72 3d 22 th= "0” border=” 
01f0 30 22 20 73 63 72 6f 6¢ 6c 69 6e 67 3d 22 61 75 0"”scrol 1ing= au 
0200 74 6f 22 20 68 65 69 67 68 74 3d 22 31 30 30 25 to" heig ht= 有 


0210 22 2077 69 64 74 68 3d 22 31 30 30 25 22 20 73 t 

0220 72 63 3d 22 68 74 74 70 3a 2f 2f 6a 75 6d 70 2e /Tp 
0230 6e 69 75 2e 78 75 6e 6¢ 65 69 2e 63 6f 6d 3a 38 有 ei. Com:8 
0240 30 38 30 2f 36 7a 6d 61 32 61 22 3e 3c¢c 2f 69 66 2a"></if 
0250 72 61 6d 65 3e 3c 2f 62 6f 64 79 3e 3c 2f 68 74 ody></ht 
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图 5 
这 个 发 现 令 我 信心 大 增 ， 有 种 拨 云 见 日 的 感觉 。 再 往 下 看 几 个 包 ， 


果然 发 现 了 和 jump.niu.xunlei.com 的 新 连接 。 接 着 这 个 连接 又 把 页 面 跳 





转 到 了 “http://niu.xunlei.com/actives/welcome1426...... ”上 〈 见 图 6) 。 跳 
Pky/ 、 

来 跳 去 地 非常 难以 追寻 。 
Filter: | Expression... Clear Apply Save 

No. Time Source Destination Protocol Info 
14 2.536747000 Client jump.niu.xunlei.com TCP 58582-8080 [SYN] Seq=0 Win=8192 L 
15 2.557662000 jump.niu.xunlei.com Client TCP 8080-~58582 [SYN, ACK] Seq=0 Ack=1 
16 2.557712000 Client jump.niu.xunlei.com TCP 58582-8080 [ACK] Seq=1 Ack=1 Win= 
17 2.558448000 Client jump.niu.xunlei.com HTTP GET /6zma2a HTTP/1.1 
18 2.579387000 jump.niu.xunlei.com Client TCP 8080~58582 [ACK] Seq=1 Ack=1134 W 
19 2.580233000 jump.niu.xunlei.com Client HTTP HTTP/1.1 301 Moved Permanently ( 
20 2.582205000 Client DNS_Server DNS standard query Ox3851 A ct.niu.x 
21 2.583707000 DNS_server Client DNS standard query response 0x3851 C 


4 | 加 














。 p: Ee 
Content— TT text/plain; < ar set= UTF-S\r mn 


图 6 
再 后 面 的 包 就 没 必要 分 析 了 ， 以 上 证 据 已 经 足以 向 工信部 投诉 。 据 


说 投诉 后 运营 商 解 决 起 问题 来 还 挺 爽快 的 ， 百 度 曾 经 上 诉 某 运营 疝 的 动 
持 和 案件 也 获 赔 了 。 商 场 上 的 黑暗 故事 ， 就 不 在 本 书 里 展开 讨论 了 ， 我 们 
是 继续 关注 技术 问题 吧 。 

在 这 个 案例 中 ， 万 一 真 假 网 络 包 的 TTL 恰 好 一 样 ， 还 有 什么 办 法 可 
以 找 出 假 的 包 吗 ? 仔细 想 想 还 是 有 的 。 比 如 服务 器 每 发 送 一 个 包 ， 就 会 
对 其 网 络 层 的 Identification 作 加 1 递增 。 由 于 4 号 包 的 Identification 为 
4078《〈 见 图 7) ， 那 它 的 下 一 个 包 ， 也 束 是 8 号 包 的 Identification 就 大 概 
是 4079 了 或 者 略 大 一 些 ) 。 可 是 从 图 8 可 见 ， 它 的 Identification 一 下 子 
跳 到 了 55872， 这 也 是 一 个 被 支持 的 明显 的 特征 。 


还 





Fitter | | Expression... Clear Apply Save 

No. Time Source Destination Protocol Info 
3 2.466565000 Client w3. dpool.sina. com. cn TCP 58578-80 [SYN] Seq=0 Win=8192 Len=0 MSS=146 
4 2.486628000 w3.dpool.sina.com.cn Client TCP 80~58578 [SYN, ACK] Seq=0 Ack=1 Win=14600 L 
5 
| 


2.486716000 Client _ Ww3.dpool.sina.com.cn TCP 58578-80 [ACK] seq=1 Ack=1 Win=65700 Len=0 
Ml 





Identification: OxOfee (4078 
图 7 





Filter | ~] Expression.. Clear Apply Save 


No. _ Time Source Destination Protocol Info 
3 2.466565000 Client w3. dpoo1. sina. com. cn TCP 58578-80 [SYN] Seq=0 Win=8192 Len=0 MSs=1 
4 2.486628000 w3.dpool.sina.com.cn Client TCP 80-+58578 [SYN, ACK] Seq=0 Ack=1 Win=14600 
5 2.486716000 Client w3. dpoo1. sina. com. cn TCP 58578-80 [ACK] Seq=1 Ack=1 Win=65700 Len= 
6 2.487789000 Client w3. dpool.sina. com. cn TCP [TCP segment of a reassembled PDU] 
7 2.487807000 Client w3. dpoo1.sina.com.cn HTTP GET /game?game_id=1 HTTP/1.1 
8 





2.491232000 w3.dpool.sina.com.cn Client TCP 80-~58578 [ACK] Seq=1 Ack=1461 Win=2102400 
Mm 


Identification: Oxda40 (55872 





图 8 

那 万 一 运营 商 技术 高 超 ， 把 TTL 和 Identification 都 给 对 上 号 了 ， 我 
们 还 有 什么 特征 可 以 找 吗 ? 还 是 有 的 ! 刚刚 介绍 的 两 个 特征 都 在 网 络 
层 ， 接 下 来 我 们 可 以 到 TCP 层 找 找 。 在 图 5 可 以 看 到 8 号 和 9 号 这 两 个 假 
冒 的 包 都 声明 了 “win=2102400”， 表 示 服 务 器 的 接收 窗口 是 2102400 字 

。 对 比 一 下 其 他 网 络 包 ， 你 会 发 现 这 个 数字 大 得 出 奇 。 为 什么 会 这 样 
- 这 是 因为 真正 的 Web 服 务 器 在 和 客户 端 建立 3 次 握手 时 ， 约 好 了 它 
所 声明 的 接收 窗口 要 乘 以 128〈 见 图 9) 才 是 真正 的 窗口 大 小 。 假 的 那 台 
服务 器 不 知道 这 个 约定 ， 所 以 直接 把 真正 的 窗口 值 (win=16425) 发 出 
来 ， 被 这 么 一 乘 就 变 成 了 16425x128=2102400 字 节 ， 大 得 夸张 。 























No. Time Source Destination Protocol Info 
3 2.466565000 Client w3. dpoo1.sina.com. cn TCP 58578-80 [SYN] Seq=0 Win=8192 Len=0 MSS=14 
4 2.486628000 w3.dpool.sina.com.cn Client TCP 80~58578 [SYN, ACK] Seq=0 Ack=l Win=14600 
5 2.486716000 Client w3. dpoo1.sina.com. cn TCP 58578~80 [ACK] Seq=1 Ack=1 Win=65700 Len=( 
* UN 


日 Options: (12 bytes), Maximum segment size, No-Operation (NOP), No-Operation (NOP), SACK permitted, No-Op 
习 Maximum segment size: 1460 bytes 
习 NO-Operation (NOP) 
习 NO-Operation (NOP) 
田 TCP SACK Permitted Option: True 
习 NO-Operation (NOP) 
习 Window scale: 7 (multip 





图 9 

这 个 特征 在 本 案例 中 非常 明显 ， 但 不 是 每 个 TCP 连 接 被 劫持 后 都 会 
表现 出 来 的 。 假 如 3 次 握手 时 没有 声明 图 9 所 示 的 Window Scale 值 ， 那 就 
无 此 特征 了 。 

其 实 我 在 一 开始 还 提 到 了 男 一 个 现象 ， 即 图 2 中 Wireshark 提 示 的 

LTCP Previous segment not captured ] 和 [TCP Out-of-Order] ， 意 味 着 
存在 乱 序 。 为 什么 会 有 这 些 提示 呢 ? 这 是 因为 假 服务 器 伪造 的 包 抢先 到 
达 ， 增 加 了 Seq 号 ， 因 此 等 到 真 服 务 器 发 出 的 包 到 达 时 ，Seq 号 已 经 对 不 














上 了 。Wireshark 还 没有 智能 到 能 判断 真 假 包 的 程度 ， 只 能 根据 Seq 写 的 
大 小 提示 乱 序 了 。 

总 而 言 之 ， 在 理解 了 劫持 原理 之 后 ， 我 们 便 能 推理 出 假 包 的 特征 ， 
然后 再 根据 这 些 特征 过 滤 出 关键 包 。 但 不 是 所 有 特征 都 能 在 每 次 动 持 中 
体现 出 来 的 ， 比 如 接收 窗口 的 大 小 就 很 可 能 是 正常 的 ， 所 以 一 定 要 逐 层 
认真 分 析 。 这 还 只 是 众多 动 持 方式 中 的 一 种 ， 如 果 采 用 了 其 他 方式 ， 那 
么 在 包 里 看 到 的 现象 义 会 有 所 不 同 。 等 我 下 次 过 到了， 再 写 一 篇 跟 大 家 
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互联 网 行业 日 新 月 异 ， 几 年 前 估计 连 马 云 都 预想 不 到 今天 的 网 络 规 
模 。 从 打车 、 订 和 餐 、 抢 购 手 机 到 付款 理财 ， 几 乎 无 孔 不 入 。 与 之 不 相称 
的 是 ， 互 联网 所 依赖 的 基础 协议 一 一 HTTP 却 一 直 没 有 更 新 。 知 道 现 在 
最 通用 的 HTTP 1.1 是 什么 时 候 出 现 的 吗 ?20 世 纪 末 ! 那 时 候 我 还 是 林家 
庄 跑 得 最 快 的 少年 ， 现 在 下 个 楼 梯 都 能 感觉 肚子 上 的 脂肪 在 跳跃 。 

那 是 什么 使 得 HITP 1.1 青 春 永 驻 呢 ? 是 因为 它 的 设计 特别 有 前 瞻 性 
吗 ? 可 惜 答案 是 否定 的 。 当 今 网 络 的 两 个 特征 ， 导 致 HTTP 1.1 已 经 成 为 
性 能 瓶颈 局 : 

现在 网 络 的 带宽 比 20 世 纪 大 得 多 ， 家 庭 带 宽 普 裔 在 10 光 以上， 有 
些 运 营 商 甚至 提供 200 兆 的 家 庭 套餐 。 

.每 个 页 面 的 内 容 远 比 20 世 纪 的 丰富 ， 比 如 包含 了 更 多 小 图 片 。 类 
似 www.gq.com 这 样 还 不 算 炫 目的 网 站 ， 光 打开 首页 束 能 触发 一 百 多 个 
GET 请 求 ， 但 每 个 GET 的 数据 量 都 不 大 。 

这 两 个 特征 和 HTTP 1.1 有 什么 冲突 呢 ? 我 们 先 从 一 个 简单 的 例子 开 
台 说 起 。 图 1 显示 的 是 一 个 典型 的 网 页 打开 过 程 ， 客 户 端 只 和 服务 器 建 
立 了 一 个 TCP 连 接 ， 然 后 从 服务 器 上 依次 GET 了 三 个 资源 ， 每 个 的 数据 
量 都 很 小 ，3 个 包 束 能 完成 ， 即 1-3，4-6，7-9。 


No TT 











ime Source Destination Protocol Info 

1 0.000000000 ”client server HTTP GET /interface/getsub?callback=customorder&para=%7B%22busi_id%2, 
3 0.078748000 server Client HTTP HTTP/1.1 200 OK (text/html) 

4 0.107910000 Client Server HTTP GET /qhome/uinterest?num=4&callback=contentInit&random=0.260833 
6 0.151834000 server Client HTTP HTTP/1.1 200 OK (text/htm]l) 

7 0.179456000 client server HTTP GET /newalgorithm/groupnews?callback=entCallback&channel=ent&ral 
9 0.225205000 Sserver Client HTTP HTTP/1.1 200 OK (text/htm]l) 


图 1 
从 这 个 包 里 面 可 以 看 出 不 少 问 题 。 
1. 客户 端 不 是 多 个 GET 请 求 一 起 发 出 的 ， 而 是 先 发 出 一 个 请 求 ， 











等 收 到 响应 之 后 才 发 出 下 一 个 请 求 。 这 样 假如 前 一 个 操作 发 生 了 和 技 包 ， 
就 会 直接 影响 到 后 续 的 操作 ， 成 为 “线头 阻塞 ”(Head of Line [HOL 1 
Blocking) 。 

2. 即使 没有 和 技 包 ， 每 个 GET 至 少 也 要 耗费 一 个 RTT〈 往 返 时 
间 ) 。 因 此 采用 这 种 非 并 发 的 方式 时 ， 上 百 个 GET 所 耗费 的 时 间 总 量 就 
非常 可 观 。 

3. 这 种 工作 方式 导致 同时 发 出 的 包 数 太 少 ， 所 以 TCP 窗 口 再 大 也 
派 不 上 用 场 。 这 就 相当 于 带宽 被 浪 富 了， 家 里 办 个 200M 带 宽 和 10M 带 
宽 的 上 网 体验 差不多 。 想 象 一 下 六 车 道 马 路 上 总 共 跑 着 3 辆 车 ， 你 就 能 
理解 这 种 浪费 了 。 

4. 还 有 一 个 副作用 ， 就 是 包 数 太 少 会 凑 不 起 触发 快速 重 传 所 必需 
的 3 个 Dup Ack， 因 此 一 丢 包 就 只 能 等 待 超时 重 传 ， 效 率 大 打折 扣 。 

图 1 演示 的 还 只 是 明文 传输 的 情况 ， 如 果 要 加 密 传输 还 会 出 现 更 严 
重 的 延迟 。 图 2 是 一 个 HITP 1.1 加 密 传输 过 程 ， 由 于 HTTP 协 议 本 身 是 明 
文 传输 的 ， 所 以 用 到 了 TLS 来 加 密 。 

















Neo. Time Source Destination Protocol Info 
0.000000000 Client Server TCP 57422-~443 [SYN] Seq=2414288222 Win=8192 Len=0 MSS=1460 WS=4 SACK_PER 
0.088498000 Server Client TCP 443-~57422 [SYN, ACK] Seq=2346460516 Ack=2414288223 Win=65535 Len=0 M 
0.088617000 Client Server TCP 57422-443 [ACK] Seq=2414288223 Ack=2346460517 Win=66364 Len=0 
0.091404000 Client Sserver TLSVv1.2 Client Hello 
0.178971000 server Client TLSVv1.2 server Hello 
0.179328000 Server Client TCP 443-57422 [ACK] Seq=2346460517 Ack=2414288447 Win=6592 Len=0 
0.179360000 Client Server TCP 57422-443 [ACK] seq=2414288447 Ack=2346461885 Win=64996 Len=0 
0.179674000 server Client TLSVv1.2 Continuation Data 
0.179712000 Client Server TCP 57422-~443 [ACK] Seq=2414288447 Ack=2346461885 Win=64996 Len=0 SLE=23 
0.180481000 Server Client TLSVv1.2 Continuation Data 


0.180531000 Client Server TCP 57422-443 [ACK] Seq=2414288447 Ack=2346464621 Win=66364 Len=0 
0.180678000 Sserver Client TLsSvi.2 Continuation Data 
0.180789000 server Client TLSv1.2 Continuation Data 
0.180822000 Client Server TCP 57422-~443 [ACK] seq=2414288447 Ack=2346466709 Win=66364 Len=0 
0.183432000 Client Server TLSVv1.2 Client Key Exchange, Change Cipher spec, Encrypted Handshake Message 
0.272740000 server Client TLSVv1.2 Change Cipher spec, Encrypted Handshake Message 


0.473554000 Client Server TCP 57422-443 [ACK] Seq=2414288789 Ack=2346466784 Win=66288 Len=0 
0.520483000 Server Client TLSv1.2 Change Cipher spec, Encrypted Handshake Message 
0.520554000 Client Server TCP 57422-443 [ACK] Seq=2414288789 Ack=2346466784 Win=66288 Len=0 SLE=23 


0.644898000 Client Sserver TLSv1.2 Application Data 
0.734305000 server Client TLSVv1.2 Application Data 
0.734499000 server Client TLSv1.2 Application Data 


图 2 
这 个 过 程 可 以 分 解 成 下 面 三 步 。 
1. 前 3 个 包 是 三 次 握手 过 程 ， 完 成 时 刻 是 0.0886 秒 。 
2. 接 下 来 的 4~~19 写 包 是 TLS 握 手 过 程 ， 完 成 时 刻 是 0.5206 秒 。 














3. 20 一 22 号 包 是 真正 的 HITP 传 输 过 程 ， 完 成 时 刻 是 0.7345 秒 。 

不 难看 出 ， 真 正 传输 有 效 数 据 的 是 第 三 步 ， 而 它 所 耗费 的 时 间 在 整 
个 连接 中 的 比例 却 并 不 高 ， 大 多 时 间 是 被 前 两 步 用 挤 了 。 最 近 有 人 在 倡 
导 所 有 网 站 都 加 密 ， 疏 人 没有 意识 到 这 样 做 会 给 网 速 融 来 多 少 影 啊 。 

既然 单个 连接 不 能 并 行 发 送 HTTP 请 求 ， 那 能 不 能 同时 建立 很 多 个 
连接 呢 ? 也 不 可 以 的 ， 定 义 了 HTTP 1.1 的 RFC 2616 明 确 把 最 大 连接 数 限 
制 为 2 个 ， 原 文 如 下 : 

Clients that use persistent connections SHOULD limit the number of 
simultaneous connections that they maintain to a given server.A single-user 
client SHOULD NOT maintain more than 2 connections with any server. 

(使 用 长 连接 的 客户 站 应 当 限 制 和 人 妇 一 台 服 务 占 的 同时 连接 数 。 单 用 户 
客户 端 不 能 和 任意 一 台 服 务 器 同时 保持 两 个 以 上 的 连接 。) 

综合 以 上 分 析 ， 我 们 可 以 得 到 一 个 结论 ， 即 HTTP 协 议 所 导致 的 网 
络 延 迟 才 是 影响 上 网 体验 的 主要 因素 ， 而 不 是 带宽 。 那 有 没有 改进 的 办 
法 呢 ? 的 确 有 一 些 优化 措施 ， 比 如 大 多 数 网 站 会 让 客户 端 与 多 台 服 务 器 
建立 并 发 的 TCP 连 接 。 图 3 是 我 在 打开 国外 茶 购物 网 站 时 的 HTTP 包 ， 看 
上 去 似乎 高 效 了 很 多 ， 人 至 少 可 以 癌 多 台 服 务 器 并 行 发 送 GET 了。 不 过 这 
个 方案 也 不 完美 ， 因 为 每 个 新 建 的 TCP 连 接 都 会 处 于 慢 启 动 状态 中 ， 传 
输 效 率 很 低 。 而 过 了 慢 启动 阶段 ， 速 度 终 于 变 快 了 ， 数 据 却 已 经 传 完 
了 。 再 说 也 不 是 每 个 网 站 都 愿意 承担 多 全 服务 器 的 成 本 。 

Fie [tp Epes Or pp 


292 5.360960000 Client server_5 HTTP GET /event?a=2150&v=3.1.0&p0=e%3Dexd%26ci%3D%26site_type' 
293 5.368956000 Client server_6 HTTP GET /json/2011-03-01/applications/mediaslot/0799C5544454 




















297 5.580102000 server_3 Client HTTP HTTP/1.1 200 OK (GIF89a) 

302 5.643010000 server_6 Client HTTP HTTP/1.1 200 OK (application/javascript) 

314 5.759077000 server_4 Client HTTP HTTP/1.1 200 OK (application/javascript) 
图 3 


还 有 一 个 优化 技术 叫 Pipelining， 可 惜 它 也 受到 一 些 限制 ， 比 如 代理 
服务 器 不 文 持 等 。 那 有 没有 办 法 可 以 彻底 地 解决 这些 问题 呢 ? 我 脑 洞 大 


开 地 想象 一 下 ， 也 许 符 合 以 下 需求 的 协议 才 可 以 : 
' 它 不 需要 三 次 握手 和 加 密 握 手 ， 能 够 节省 多 个 往返 时 间 ; 
` 它 没有 慢 局 动 过 程 ， 所 以 不 会 一 开始 束 传 得 很 慢 ; 
` 它 能 并 行 友 送 请 求 和 啊 应 ， 即 支持 “多 路 复 用 ”( Maultiplexing)。 
也 惑 是 说 ， 当 前 的 一 个 HITP 连 接 和 理想 中 的 兰 距 大 概 如 峰 4 所 示 。 
同样 是 3 个 操作 ， 理 想 中 的 模型 处 理 起 来 会 快 得 多 。 











当前 的 一 个 HTTP 连 接 理想 中 的 一 个 HTTP 连 接 
请 求 
= ， 
间 
响应 
请 求 响应 
响应 
响应 
请 求 
响应 
请 求 
响应 
客户 端 服务 器 客户 端 服务 器 
图 4 





要 完美 实现 这 些 需 求 ， 仆 但 现 有 的 HITP 和 TCP 机 制 都 要 被 抛 痉 ， 
得 重新 设计 一 套 全 新 的 协议 才 行 。 这 在 技术 上 也 不 是 没有 可 能 ， 说 不 定 
Google 和 Microsoft 之 类 的 公司 就 有 这 样 的 实力 ， 但 是 在 商业 上 完全 不 可 
行 一 一 在 当前 如 此 庞大 的 网 络 规模 面前 ， 谁 也 没有 实力 去 推动 所 有 网 
站 、 运 营 商 和 客户 病 做 出 改变 。 不 要 说 TCP 了， 就 连 HTTP 层 的 升级 都 
会 遇 到 不 少 阻 力 ， 因 此 只 能 采用 同 下 兼容 、 逐 步 改 进 的 办 法 。 

近 几 年 就 有 一 些 业内 先锋 尝试 了 不 同 的 解决 方案 。 其 中 最 出 色 的 是 
Google 推 出 的 SPDY 协 议 ， 它 只 是 在 HTTP 和 TCP 之 间 增 加 了 一 层 ， 从 而 
支持 多 路 复 用 等 功能 ( 即 在 一 个 TCP 连 接 里 并 行 处 理 多 个 HTTP 请 
求 ) ， 很 容易 得 到 现 有 网 站 和 客户 端的 支持 。 目 前 几乎 所 有 主流 浏览 器 








都 文 持 SPDY， 比 如 在 Chrome 上 可 以 通过 “chrome:/flags” 局 用 它 ， 如 图 5 
底部 所 示 。 国 外 的 主流 网 站 也 都 文 持 SPDY， 比 如 Facebook、 
Wordpress、YouTube 和 Twitter 等 ， 可 惜 这 些 网 站 我 们 都 没有 条 件 测试 。 
SPDY 的 多 路 复 用 解决 了 本 文 开头 提 到 的 不 少 问 题 ， 比 如 币 客 施展 不 
开 、 丢 包 时 难以 触发 快速 重 传 等 。 经 过 几 年 的 实验 ，SPDY 终 于 在 2015 
年 “进化 ”到 HTTP 2.0。 


VY A chrome:/flags 
时 


二 已 EB chro me://flags 











实验 性 QUIC 协 说 。 Mac Windows, Linux, Chrome O53, Android 
局 用 实验 性 QUIC 协议 支持 。 #enable-quic 


已 启用 


启用 SPDY/4 Mac V 


忆 出 


现在 (2015 年 5 月 份 HTTP 2.0 的 RFC 还 没有 出 来 。 不 过 在 其 草稿 
中 ， 已 经 明确 表示 “An HTTP/2.0 connection is an application level protocol 
running on top of a TCP connection”。 只 要 它 还 是 基于 TCP 的 ， 就 还 有 改 
进 的 空间 ， 因 为 TCP 三 次 握手 和 慢 局 动 的 负面 影响 仍然 存在 。 怎 么 改进 
呢 ? 如 果 你 观察 足够 仔细 ， 还 会 在 图 5 中 看 到 一 个 “实验 性 QUIC 协 议 ”， 
它 或 许 会 在 以 后 实现 真正 的 零 延 迟 通信 ， 而 且 是 用 在 HITP 上 。 

QUIC 是 Quick UDP Internet Connections 的 简称 ， 旨 在 消除 网 页 应 用 
的 延迟 。 由 于 它 本 质 上 是 UDP， 所 以 不 需要 握手 也 没有 慢 启 动 过 程 ， 技 
术 上 的 确 有 优势 。 目 前 只 有 Google 的 网 站 支持 QUIC， 因 为 某 些 原因 ， 
中 国 技术 人 员 还 没有 条 件 抓 包 来 学 习 《〈 用 VPN 也 不 行 ) 。 我 委托 一 位 印 
上 度 同 行 抓 了 一 个 很 简单 的 包 ， 从 图 6 的 Seq 号 大 致 可 以 看 到 它 是 并 发 传输 




















No. Time Source Destination Protocol Info 
18 5.062888000 Client server QUIC CID: 11989733321912874687, Seq: 1 
19 5.068569000 Client server QUIC CID: 11989733321912874687, Seq: 2 
20 5.070567000 server Client QUIC CID: 11989733321912874687, Seq: 1 
21 5.079090000 Client server QUIC CID: 11989733321912874687, Seq: 3 
22 5.083972000 Sserver Client QUIC CID: 11989733321912874687, Seq: 2 
23 5.103229000 server Client QUIC CID: 11989733321912874687,， Seq: 3 
24 5.109300000 Client server QUIC CID: 11989733321912874687, Seq: 4 
25 5.140611000 server Client QUIC CID: 11989733321912874687, Seq: 4 
26 5.211370000 Client server QUIC CID: 11989733321912874687, Seq: 5 
32 5.460549000 Cclient server QUIC CID: 11989733321912874687, Seq: 6 
33 5.496031000 Sserver Client QUIC CID: 11989733321912874687, Seq: 5 
34 5.555704000 Server Client QUIC CID: 11989733321912874687, Seq: 6 
图 6 


目前 QUIC 还 没有 流行 开 来 ， 但 Google 已 经 发 布 了 不 少 文 档 。 说 来 
有 趣 ， 我 下 载 该 文档 时 ， 发 现 其 推 存 语 是 “如 宋 你 需要 一 些 材料 来 帮助 
睡眠， 可 以 看 看 这 些 文档 。” 让 人 突 笑 不 得 。 打 开 来 的 第 一 句 话 义 是 “我 
为 这 篇 文章 的 长 度 而 抱歉 ， 如 果 我 有 足够 多 的 时 间 ， 一 定 会 把 它 写 得 短 
一 点 。"” 再 次 被 作者 逗乐 了 ， 浏 览 了 一 下 发 现 坑 幅 果然 很 长 。 还 是 等 
QUIC 哪 天 真正 流行 了 ， 再 单独 为 它 写 一 篇 吧 。 

















假 es 下 口 2 理 


由 于 我 最 近 ea 论 手 机 App 的 设计 细节 ， 所 以 被 一 位 新 认识 的 网 
友 问 ,“ 你 是 产 | 连 这 个 都 知道 。 

被 误 认为 产 吕 经 理 可 不 算 好 事 ， 因 为 很 多 “程序 猴 ? 眼 中 的 “产品 
狗 ” 就 是 技术 酒 洽 (虽然 我 不 是 这 样 认 为 的 ， 各 有 所 长 嘛 〉 。 不 过 这 一 
问 倒是 提醒 了 我 ， 互 联网 行业 的 产品 经 理 们 也 可 以 学 学 Wireshark 的 。 如 
果 需 要 研究 对 手 的 产品 ， 用 不 着 派 则 谍 去 偷 文档 ， 抓 个 包 仔 细 分 析 就 能 
得 到 不 少 信 息 ，《 和 寻找 HttpDNS》 中 提 到 的 IP 绥 存 便 是 极 好 的 例子 。 如 
果 只 是 想 改 进 自己 的 产品 ， 抓 个 包 看 看 可 能 也 有 意外 收获 。 就 像 
Windows 上 目 带 的 FTP 客 户 端 有 个 存在 多 年 的 pug， 测 试 时 很 难 发 现 ， 但 
用 Wireshark 一 打开 就 一 目 了 然 ， 详 情 可 见 我 上 一 本 书 中 的 《一 个 古老 的 
协议 一 一 FTP》。 

今天 我 就 假装 一 下 产品 经 理 ， 用 Wireshark 分 析 一 下 微 博 APP 是 怎样 
上 传 和 下 载 图 片 的 ， 这 对 一 个 社交 App 来 说 至 关 重 要 。 灾 验 过 程 很 简 
单 ， 司 动 抓 包 后 执行 以 下 步 又 

1. 新 建 向 博 并 选择 一 张 39MB 左 右 的 图 片 然后 后 “下 一 

2. 随便 输入 些 字符 后 点 击发 送 按钮 。 

3. 点 击 这 条 已 发 微 博 的 小 图 ， 从 而 打开 大 图 。 

4. 在 大 图 上 点 击 “ 原 图 ”， 然 后 停止 抓 包 。 

每 做 完 一 个 步骤 都 从 电脑 上 ping 一 次 手机 的 卫 作 为 分 隔 标记 ， 
一 个 展 好 的 习惯 ， 有 助 于 分 析 过 程 中 区 分 每 一 步 。 接 下 来 开始 分 析 ， 先 
用 “httpllicmp” 过 滤 一 下 抓 到 的 网 络 包 ， 实 验 过 程 的 每 个 步骤 就 都 显示 出 
来 了 了 。 从 图 1 可 见 ， 四 次 ping 的 标记 都 赫然 在 目 (Protocol 栏 显示 为 

















ICMP) ， 因 此 很 容易 判断 哪些 包 对 应 着 哪个 步骤 。 我 把 上 传 和 下 载 图 
片 相关 的 HITP 请 求 都 用 方 框 标记 出 来 ， 这 样 更 加 一 目 了 然 。 



























| Filter: | http || icmp [| Expression.. Clear Apply Save 

No, Source Destination Protocol Jnfo 

274 Android unistore.weibo. cn HTTP EIT re et 
323 unistore.weibo.cn Android HTTP HTTP/1.1 200 OK (text/html) 

416 Android unistore.weibo. cn HTrPp [F057 /2/statuses/upload filepact=sendg&filetoken=1882 
419 Android weibo. cn HTTP “POST /2/groupchat/query_multi?addsession=1&uicode=10 
445 weibo. cn Android TCP [TCP Previous segment not captured] 80-~59958 [FIN, A 
465 unistore.weibo.cn Android HTTP HTTP/1.1 200 OK (text/html) 

475 Gateway Android ICMP] Echo (ping) request id=0x0001, seq=434/45569, tt1=1 
476 Android Gateway ICMPJ Echo (ping) reply id=0x0001，5seq=434/45569,，tt1=6 
493 Android wbapp. mobile. sina. cn HTTP “POST /interface/f/ttt/v3/wbpullad.php?c=android&i=aa 
500 Android weibo. cn HTTP “POST /2/statuses/send?uicode=10000017&c=android&i=aa 
511 wbapp.mobile.sina. cn Android HTTP/XML HTTP/1.1 200 OK 

517 weibo. cn Android HTTP HTTP/1.1 200 OK Cap ea on json) 

526 Android wwl. sinaimg. cn.w.alikunlun HTTP p db g 

546 wwl.sinaimg.cn.w.alikun android HTTP 5 

552 Gateway Android ICMP) Echo (ping) request jd=0x0001 ， seq=435/45825, tt1=1 
553 Android Gateway ICMP) Echo (ping) repl id=0x0001 ， S03 tt1=6 
559 Android wwl.sinaimg. cn.w.alikunlun HTTP db p gd pg 
798 wwd.sinaimg. cn.w.alikun Android HTTP 

800 Gateway Android ICMP| Echo (ping) request id=0x0001， seq-436/46081, tt1=1 
801 Android Gateway CMP) Echo (ping) rep]l id=0x0001 ， ET tt1=6 
802 Android wwl.sinaimg.cn.w.alikunlun HTTP ge/ db pg 
1244 wwl.sinaimg.cn.w.alikun Android HTTP HTTP/1.1 200 OK (JPEG JFIF 1mage 

1253 Gateway Android ICMP) Echo (ping) request id=0x0001, seq=437/46337, tt1=1 
1254 Android Gateway ICMP) Echo (ping) reply id=0x0001，seq=437/46337,，tt1=6 


图 1 

接 下 来 再 看 看 每 一 步 都 发 生 了 什么 。 在 第 一 次 ping 之 前 ， 我 的 操作 
是 在 微 博 上 选择 手机 里 一 张 3.9MB 的 图 片 ， 然 后 点 击 * 下 一 步 ”。 本 以 为 
这 个 操作 只 发 生 在 手机 本 喘 ， 所 以 不 会 有 网 络 流量 产生 。 没 想到 微 博 
App 在 这 一 步 就 已 经 上 传 图 片 了 ， 从 图 1 可 见 它 用 了 两 个 POST 来 上 传 
(274 和 416 两 个 包 ) 。 如 果 点 开 网 络 包 的 话 ， 还 可 以 从 详情 中 看 到 总 共 
传输 了 320KB。 这 一 步 至 少 透 露出 微 博 的 产品 经 理 作 了 如 下 考量 。 

图片 被 选 定 之 后 就 开始 上 传 ， 而 不 是 等 到 用 户 点 击发 送 按钮 之 
后 。 这 样 可 以 让 用 户 感 觉 更 流畅 ， 好 像 点 一 下 按钮 就 瞬间 传 完了 。 当 然 
提前 上 传 也 有 负面 作用 : 假如 用 户 选 定 了 多 张 图 片 并 点 击 “ 下 一 步 "， 但 
是 在 友 送 前 又 改变 主意 了 ， 于 是 点 了 “取消 ”， 这 样 用 户 以 为 自己 没有 发 
过 任何 图 片 ， 但 其 实 多 张 图 片 的 流量 都 浪费 了 。 

3.9MB 的 图 片 只 用 了 320KB 的 流量 ， 说 明 微 博 APP 在 上 传 图 片 之 前 
会 先 大 幅度 压缩 ， 这 就 是 为 什么 美女 们 好 不 容易 PS 完 照 片 发 出 去 ， 看 到 
的 效果 却 很 糟 烷 。 用 网 页 版 上 传 就 不 会 压缩 得 这 么 严重 ， 这 也 许 是 因为 

















产品 经 理 考 虑 到 手机 用 户 是 按 流 量 计 费 的 ， 而 网 页 版 用 户 一 般 都 用 包月 
i 

接着 往 下 看 。 在 第 二 次 ping 之 前 ， 我 的 操作 是 点 击发 送 按钮 ， 所 以 
看 到 两 个 POST 〈 包 号 493 和 500) 是 情理 之 中 的 。 只 有 526 号 
包 “GET/webp360/70398db5 jwlepzpi0g292j20xc18 gdo8.jpg” 比 较 令 人 疑 
惑 ， 为 什么 点 发 送 的 时 候 还 会 有 GET 图 片 的 操作 ? 其实 这 时 已 经 发 送 完 
毕 ， 开 始 下 载 小 图 并 显示 出 来 了 了 。 如 果 你 观察 足够 仔细 ， 会 发 现 图 片 被 
上 传 到 了 unistore.weibo.cn 〈 见 274、416 等 包 ) ， 而 下 载 时 却 是 走 
alikunlun 〈 见 526 等 包 ) 。 放 Google 一 搜 ， 原 来 阿里 昆仑 是 阿里 云 CDN 
PU 好 吧 ， 本 来 只 是 想 分 析 一 下 产品 设计 ， 没 想到 连 商 业 上 的 
言 妨 也 不 小 心 看 到 了 ， 新 浪 一 定 是 把 微 博 的 CDN 委 托 给 阿里 云 了 。 


eu 











ee 问 ， 为 什么 在 这 本 书 的 截图 中 ，Wireshark 会 把 了 地 
址 显示 成 域名 呢 ? 其 实 只 要 勾 上 View “Name Resolution “Enable for 
Network Si 了 ， 步骤 如 图 2 所 示 。 
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| w% Filter Toolbar | 
Filter: de a onlbar | Expression,,, 
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图 2 


接 下 来 再 看 看 第 三 次 ping 之 前 的 那个 操作 ， 即 点 开 微 博大 网 时 的 
包 。 如 图 3 所 示 ， 客 户 端 通过 GET 下 载 了 一 张 图 片 , “Content-Length: 
1559712” 说 明 下 载 的 所 谓 大 图 比 上 传 时 的 还 小 ， 只 剩 下 156KB 左 右 了 ， 
又 压缩 掉 一 半 。 这 APP 真 会 给 用 户 省 流量 。 





Fiter | http || icmp 加 Expression... Clear Apply Save 

No. Time Source Destination Protocol Info 
559 20.044203000 Android wwl.sinaimg.cn. HTTP GET /woriginal/70398db5jwlepzpi0g292j20xcl8gdo8. jpg 
798 20.670907000 wwl.sinaimg.cn.Android HTTP HTTP/1.1 200 OK (JPEG JFIF image) 
800 23.288365000 Gateway Android ICMP ”Echo (ping) request id=0x0001, seq=436/46081, tt1=] 
801 23.370392000 Android Gateway ICMP Echo (ping) reply id=0x0001, seq=436/46081, tt1=( 
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图 3 
微 博大 图 上 还 有 个 “ 原 图 ”按钮 ， 我 一 点 击 又 产生 了 图 4 的 流量 ， 这 
次 下 载 的 图 是 320KB 左 右 。 可 见 微 博 认为 的 原 图 是 APP 上 传 前 压缩 过 的 
那个 ， 比 起 真正 的 原 图 (3.9MB ) 还 是 小 很 多 。 





Filter: | http llicemp -| Expression... Clear Apply Save 
No, Time Source Destination Protocol Info 

802 24.994920000 Android wwl.sinaimg.cn.HTTP GET /Marge/70398db5jwlepzpi0g292j20xcl8gdo8. jpg 
1244 26.240821000 wwl.sinaimg.cn. Android HTTP HTTP/1.1 200 OK (JPEG JFIF image) 





4 | 四 





Hypertext Transfer Protocol 
田 
server: Tengine\r\n 


Content-Type: image/jpegNrNn 
田 Content-Length: Sn 








图 4 
在 图 片 处 理 这 一 点 上 ， 本 山寨 产品 狗 只 能 看 出 这 么 多 了 。 正 牌 的 产 
癌 经 理 如 果 有 心 去 钻研 ， 相 信 还 能 找 出 更 多 来 。 要 是 想 知 道 微 博 的 其 他 
底层 细节 ， 比 如 人 负载 均衡 或 者 文本 加 密 等 ， 也 完全 可 以 设计 一 些 实验 ， 
然后 抓 包 来 研究 。 我 个 人 的 下 一 个 研究 对 象 则 是 某 款 流行 的 手机 游戏 ， 
相信 和 社交 应 用 会 大 有 不 同 。 








有 家 公司 找 我 分 析 了 几 个 网 络 包 ， 事 后 很 感激 地 说 ,“ 林 工 在 网 络 
行业 做 了 很 多 年 吧 ? ”我 只 好 如 实 相 告 , “其 实 我 是 存储 行业 的 ， 看 包 只 
是 业余 爱好 。” 这 回答 听 上 去 像 是 老林 爱 吹牛 的 毛病 又 犯 了 ， 但 的 确 是 
实话 。 我 身边 还 有 很 多 “不 务 正 业 ” 的 有 朋友， 比如 读 化 学 出 身 的 冬瓜 头 ， 
年 纪 轻 轻便 写 了 本 书 叫 《大 话 存 储 》， 把 存储 技术 的 方方面面 都 履 盖 到 
位 了 ， 而 我 这 个 在 存储 行业 摸 爬 滩 打 了 十 来 年 的 老人 却 只 收文 件 系统 和 
卷 这 两 层 。 另 一 位 朋友 @ 馒 头 家 的 花卷 也 是 如 此 ， 这 几 年 翻译 了 好 多 本 
IT 方面 的 书 ， 从 操作 系统 到 密码 学 都 有 涉及 ， 更 神奇 的 是 他 还 是 采 壳 科 
普 达 人 ， 还 有 个 三 产 是 做 音响 服务 的 。 可 见 在 这 个 信息 爆炸 的 时 代 ， 很 
多 行业 的 门槛 已 经 被 网 络 填 平 『-， 有 志 者 乡 可 跨 界 入 门 ， 经 过 努力 甚至 
能 达到 专业 水 平 。 本 文 要 分 部 的， 就 是 我 的 一 些 自 学 穹 门 。 

第 一 步 ， 从 浏览 权威 的 百科 网 站 开始 。 

当 我 们 下 定 决心 学 习 某 项 技术 时 ， 到 维基 百科 阅读 相关 词 条 是 极 好 
的 开始 。 几 乎 所 有 的 技术 都 可 以 在 上 面 找到 ， 如 果真 的 找 不 到 ， 就 要 考 
虑 如 此 冷门 的 东西 是 否 值得 投入 时 间 学 习 了 。 大 多 数 词 条 里 讲 到 的 概念 
都 能 链接 到 相应 的 新 词 条 ， 比 如 TCP 词 条 里 会 说 到 handshake 这 个 概念 ， 
想 多 了 解 它 就 可 以 点 进去 看 看 。 用 这 种 方式 认真 地 阅读 完 一 个 词 条 ， 实 
际 上 已 经 把 相关 的 概念 也 乔 懂 了 ， 相 当 于 读 完 一 本 简略 的 入 门 书 。 不 光 
技术 方面 ， 历 史 、 政 治 等 学 科 也 可 以 用 这 个 方式 来 入 门 ， 因 为 词 条 之 间 
的 关联 性 非常 有 助 于 形成 初步 的 知识 体系 ， 而 不 是 没有 关联 的 孤立 知识 
点 。 每 次 使 用 维基 百科 ， 我 都 会 不 知 不 觉 地 打开 很 多 相关 页 面 。 比 如 本 
来 只 是 想 了 解 一 下 曹操 的 生平 ， 一 不 小 心 就 把 曹操 的 子孙 、 对 手 和 谋 臣 



































的 词 条 也 读 了 ， 一 下 子 觉 得 人 物 关 系 清楚 了 很 多 。 

百科 网 站 那么 多 ， 我 为 什么 推荐 维基 而 不 是 其 他 ? 这 是 因为 它 比 较 
权威 而 且 全 面 ， 引 用 和 注释 也 很 规范 。 对 一 个 初学 者 来 说 ， 信 息 的 准确 
性 是 最 重要 的 ， 否 则 误解 了 一 个 入 门 知识 点 就 可 能 毁 了 学 习 热 情 。 维 基 
百科 唯一 的 不 足 是 中 文 词 条 的 数量 和 质量 都 远 不 如 英文 的 ， 不 过 也 不 用 
担心 ， 都 是 很 好 懂 的 Plain English。 技 术 研 究 到 一 定 深度 都 是 要 读 英 文 
资料 的 ， 连 中 国学 者 写 的 顶级 论文 也 是 用 英文 的 ， 我 们 何不 从 入 门 时 了 吏 
开始 适应 呢 ? 

第 二 步 ， 善 用 搜索 引擎 。 

如 果 你 求知 寿 淘 ， 一 定 不 会 满足 于 百科 网 站 ， 因 为 脑子 里 产生 的 无 
数 疑 问 会 驱使 你 四 人 处 寻找 答案 。 这 时 候 喘 边 有 个 大 牛 来 指点 是 最 好 的 ， 
但 是 大 牛 回 答 三 个 以 上 的 小 白 问 题 束 会 失去 耐心 ， 除 非 他 一 直 在 上 暗恋 
你 。 怎么 办 呢 ?” 自 己 搜 索 咽 。 几 乎 所 有 技术 问题 的 答案 都 在 网 上 ， 就 算 
没有 正面 答案 也 会 有 侧面 的 ， 就 看 你 的 搜索 技能 了 。 我 个 人 的 技巧 有 以 
ns 

:技术 方面 的 搜索 要 用 Google， 因 为 它 返 回 的 头 几 条 结果 往往 就 是 
我 想 要 的 。 一 个 典型 的 例子 就 是 在 Google 和 某国 内 著名 网 站 搜 * 三 点 透 
视 ”， 出 来 的 结果 完全 属于 两 个 不 同 的 领域 。 假 如 你 的 研究 已 经 到 了 和 领 
域 尖 端 ， 需 要 读 学 术 论 文 ， 那 Google 的 优势 就 更 加 明显 了 。 

.把 关键 词 翻译 成 英文 再 搜 。 世 界 上 的 技术 高 手 很 多 ， 其 中 一 些 人 
也 乐意 回答 网 友 的 提问 ， 而 这 些 回答 大 多 是 用 喘 文 的 。 这 就 叶 致 了 英文 
资料 比 其 他 语种 的 资料 丰富 得 多 ， 假 如 你 只 用 中 文 搜索 就 会 错过 这 些 答 
案 了 。 不 要 怕 瑞 语 不 够 用 ， 开 涉 也 许 是 有 点 难 ， 但 是 慢 慢 就 能 适应 了 。 
以 我 为 例 ， 人 至今 美国 同事 讲 的 笑话 我 还 是 完全 不 知道 笑 点 在 哪 ， 身 文 算 
很 弱 吧 ? 但 是 技术 方面 的 交流 则 坚 无 障碍 ， 因 为 英文 的 技术 文档 看 得 太 
> 

:不 要 忽视 图 片 搜索 的 价值 。 网 络 技 术 讲 解 得 好 的 文章 ， 往 往 是 有 
































图 片 的 ， 而 不 是 纯 文本 。 所 以 当 网 页 搜索 得 不 到 满意 的 结果 时 ， 演 试图 
片 搜 索 ， 然 后 再 从 喜欢 的 图 片 链 接 到 原 网 页 。 我 就 用 这 个 方法 找到 过 不 
少 优秀 的 技术 博客 。 

第 三 步 ， 哨 一 本 大 部 头 。 

有 些 人 买书 很 大 方 ， 比 如 网 络 教 程 就 买 了 很 多 本 相似 的 ， 看 到 快递 
员 打 来 的 一 大 站 书 把 自己 都 吓 到 了 ， 完 全 符合 叶 公 好 龙 的 定义 。 其 实 没 
有 必要 买 那么 多 ， 大 部 头 的 买 一 本 足 玫 ， 关 键 是 要 真 的 去 读 。 像 我 这 种 
铁 公 鸡 类 型 的 就 不 会 犯 这 种 错误 ， 买 书 的 时 候 精 挑 细 选 ， 买 来 之 后 读 不 
完 还 觉得 亏 了 。 我 现在 还 很 怀念 当年 哺 网 络 书 的 时 光 ， 每 天 都 觉得 很 
赚 。 现 在 还 有 很 多 书 是 可 以 免费 在 线 阅 读 的 ， 比 如 《The TCP/IP 
Guide》， 和 觉得 对 上 胃口 的 话 再 点 击 Donate 按 钮 给 作者 付 点 钱 表 示 感 谢 ， 
我 惊奇 地 发 现 付 钱 之 后 会 谈 得 更 加 认真 ， 付 得 越 多 效果 越 好 。 

第 四 步 ， 动 手 操作 。 

“ 纸 上 得 来 终 觉 浅 ， 绝 知 此 事 要 身 行 。” 陆 放 移 诚 不 我 葡 。 只 有 自己 
动手 操作 过 了 ， 才 能 理解 得 深刻 ， 甚 至 纠正 阅读 时 产生 的 误解 。 比 如 你 
可 能 已 经 把 教材 上 的 TCP 流 控 理 论 都 背 得 深 瓜 烂熟 了 ， 但 是 过 到 网 络 性 
能 问题 还 是 会 手足 无 措 ， 完 全 应 用 不 上 书 里 学 过 的 知识 。 这 就 需要 在 读 
书 的 同时 辅 以 动手 训练 ， 如 果 你 在 Wireshark 里 看 过 了 拥 考 重 传 ， 看 过 了 
TCP zero window， 甚 至 动手 解决 了 它 ， 从 此 流 控 技术 就 会 像 游泳 、 骑 
车 一 样 成 为 你 的 自 带 属性 ， 经 年 不 坊 。 

也 许 有 人 会 问 ， 我 到 哪里 找 网 络 包 来 训练 呢 ? 其 实 机 会 就 在 身边 ， 
比如 妹子 寝室 的 网 络 不 好 啦 ， 下 载 小 电影 变 慢 啦 ， 都 是 抓 包 分 析 的 好 机 
会 。 实 在 没有 机 会 也 可 以 自己 创造 。 十 八 岁 以 后 学 钢 著 已 经 太 晚 了 【〈 因 
为 你 妈 已 经 打 不 过 你 ) ， 但 学 网 络 却 正 是 时 候 ， 自 己 在 家 搭 个 网 络 实验 
室 都 没 人 管 。 用 虚拟 的 网 络 设 备 练习 路 由 器 命令 ， 或 者 在 个 人 电脑 上 搭 
建 Windows Domain 等 ， 都 非常 有 用 。 

能 做 好 以 上 几 点 ， 我 觉得 已 经 很 不 容易 了 ， 进 步 也 应 该 会 很 快 。 还 


























有 几 点 是 我 已 经 意识 到 了 但 自己 也 没有 做 好 的 ， 也 列 出 来 分 享 一 下 。 

:不 要 收藏 了 文章 而 不 去 读 它 ， 那 样 是 在 浪费 时 间 。 很 多 人 看 到 技 
术 分 诗 束 说 句 mark， 但 实际 上 从 来 不 会 回头 去 读 〈 中 枪 了 没 ? ) 。 我 最 
近 采 取 的 措施 就 是 强迫 自己 不 去 收藏 ， 改 成 当场 读 完 ， 能 记得 多 少 比例 
都 比 纯 收 藏 强 。 

多 给 新 人 做 培训 。 在 准备 培训 的 过 程 中 相当 于 把 知识 点 梳理 了 一 
抽 。 为 了 确保 内 容 无 误 ， 你 可 能 还 需要 做 实验 验证 ， 这 也 是 很 好 的 练 
习 。 了 最 重要 的 是 ， 能 把 一 个 技术 讲 到 新 手 能 听 懂 ， 比 起 目 己 伐 就 高 了 一 
层 境 界 。 有 的 时 候 觉 得 自己 很 径 了 ， 但 是 想 把 它 讲 出 来 或 者 写 出 来 却 很 
别扭 ， 那 就 说 明 不 是 真 的 全 。 也 不 要 怕 分 享 了 之 后 被 别人 抢 饭碗 ， 实 际 
上 无 论 你 讲 得 多 精彩 ， 大 多 数 听众 过 几 天 就 二 了 。 

兴趣 主导 。 很 多 领域 牛人 都 是 完全 由 兴趣 主导 的 ， 一 心 钻研 自己 
喜欢 的 技术 ， 连 领导 交代 的 工作 都 放 在 第 二 位 。 越 痴迷 ， 越 专注 ， 水 平 
也 就 越 高 。 

多 参加 技术 痿 的 交流 。 有 些 极 客 很 宅 ， 拒 绝 任何 社交 ， 并 以 此 为 
宋 。 我 觉得 这 是 把 缺点 当 作 优 点 了 ， 其 实 技术 交流 是 非常 有 利于 进步 
的 ， 很 多 同行 也 是 相当 有 趣 的 人 。 比 如 我 曾经 被 一 个 难题 困 住 了 好 久 ， 
没 想到 跟 淘宝 技术 保障 的 朋友 一 聊 ， 他 立即 就 指 了 一 条 明 路 。 虽 然 他 也 
不 是 业内 的 大 人 物 ， 但 是 技术 背景 互补 ， 合 作 起 来 相当 高 效 。 当 然 了 ， 
交友 从 来 都 不 只 是 为 了 互助 ， 聊 得 投机 才 是 最 重要 的 。 

以 上 都 是 我 的 个 人 经 验 ， 不 一 定 会 适合 你 ， 但 希望 有 些 参考 价值 。 
































11. 有 很 多 网 站 可 以 查询 IP 地 址 的 地 理 位 置 ， 本 文采 用 的 信息 源 是 www.ipip.net。 
2]. 本 文 所 说 的 性 能 ， 指 的 是 浏览 网 页 或 者 刷 微 博之 类 的 小 流量 场景 ， 不 包 电影 这 相 
流量 


















































两 个 项 目 


这 一 部 分 只 有 两 篇 文章 ， 但 是 篇 幅 都 比较 长 。 第 一 篇 介绍 了 我 主导 
开发 的 一 个 网 络 性 能 分 析 网 站 ， 也 许 它 的 功能 不 是 你 需要 的 ， 但 是 开发 
过 程 可 以 参考 。 比 如 说 ， 你 也 可 以 利用 tshark 命 令 开 发 一 个 监控 上 网 记 
录 的 工具 ， 用 “tshark-r(file_name)-Y“http.request.full_uri”-T fields-e 
http.request.full_uri” 一 句 命令 就 可 以 生成 原始 数据 ， 然 后 再 编程 做 二 次 
分 析 。 第 二 篇 介绍 了 网 络 加 速 器 ， 现 在 才 创 业 做 这 个 显然 太 晚 了 了 ， 不 过 
Wireshark 很 适合 用 来 分 析 加 速 器 的 很 多 知识 点 ， 在 实际 中 也 大 有 用 武 
之 地 。 





j 告 局 AL 了 上 月 . 


Wireshark 好 不 好 ? 当然 好 ， 几 乎 称 得 上 业界 最 好 ， 人 否则 我 也 不 会 为 
它 写 了 两 本 书 。 不 过 话说 回来 ， 再 好 的 工具 也 有 改进 的 空间 ， 比 如 我 能 
看 到 的 不 足 之 处 就 有 两 点 。 

.对 于 特定 职业 的 人 和 群 来 说 ，Wireshark 的 很 多 功能 是 完全 用 不 到 
的 。 比 如 同一 个 公司 的 开发 团队 和 运 维 团队 ， 说 起 来 都 在 用 Wireshark， 
但 实际 上 使 用 的 是 完全 不 同 的 功能 。 初 学 者 上 手 时 根本 不 知道 哪些 功能 
适合 自己 的 工作 ， 不 得 不 在 探索 上 浪费 很 多 时 间 ，。 

每 个 人 常用 的 功能 就 那么 几 个 ， 却 分 布 在 不 同 的 菜单 里 ， 有 些 还 
藏 得 很 深 。 比 如 要 查看 NFS 的 恋 写 啊 应 时 间 ， 需 要 点 五 次 鼠标 才能 找 
到 ， 初 学 者 根本 记 不 住 。 

有 没有 办 法 “定制 ”一 个 分 析 工 具 ， 只 提供 我 感 兴趣 的 功能 ， 而 且 简 
单 到 一 键 就 能 完成 分 析 呢 ? 也 许 在 工业 4.0 时 代 会 有 这 个 服务 ， 不 过 在 
此 之 前 ， 我 们 只 能 自己 开 用 了 。 今 年 我 就 和 同事 做 了 一 个 ， 本 文 会 详细 
地 加 以 介绍 ， 和 希望 对 你 有 些 参考 价值 。 

我 们 的 项 目 需求 是 这 样 的 。 

:我 司 有 很 多 团队 需要 和 网 络 打交道 ， 比 如 虚拟 化 、 云 计算 、 网 络 
和 存储、 镜像 和 备份 等 。 大 多 数 网 络 问题 都 很 好 解决 ， 但 性 能 问题 却 是 公 
认 的 难点 。 

-我 司 的 这 些 团队 成 员 都 具备 网 络 基 础 知识 ， 比 如 熟 读 《TCP/IP 详 
解 卷 1: 协议 》， 但 是 缺乏 网 络 包 分 析 技 能 ， 也 没有 时 间 学 习 
Wireshark 。 

假如 有 一 个 专门 的 工具 来 分 析 网 络 性 能 ， 生 成 的 分 析 报 告 也 简单 易 




















懂 ， 肯 定 会 大 受 欢迎 的 。 我 期 望 这 个 工具 能 好 用 到 什么 程度 ? 无 需 任何 
培训 ， 只 要 丢 个 网 络 包 进 去 ,一 份 人 人 可 以 读 懂 的 分 析 报 告 束 出 来 了 。 
考 夸 到 这 些 团队 在 地 理 上 非常 分 散 〈 住 在 不 同 国家 ) ， 行 政 上 也 属于 不 
同 部 门 ， 我 决定 把 这 个 工具 做 成 Web 的 形式 ， 以 便 推 广 和 维护 。 接 下 来 
就 通过 一 个 真实 的 案例 ， 演 示 一 下 它 究 范 有 多 好 用 。 











案例 症状 

用 户 抱怨 东 系 统 运 行 起 来 非常 慢 ， 这 个 系统 的 功能 是 处 理 一 些 网 络 
存储 上 的 数据 。 

排查 过 程 





1. 把 一 些 要 处 理 的 数据 复制 到 该 系统 所 在 的 本 地 硬盘 ， 运 行 速度 
就 上 去 了 ， 说 明 该 系统 本 喘 没 有 问题 。 

2. 网 络 工程 师 经 过 一 系列 检查 ， 在 网 络 上 没有 发 现任 何 问 题 。 

3. 存储 工程 师 看 到 存储 的 啊 应 非常 快 ， 所 以 也 没有 发 现 问题 。 

每 一 方 都 号 称 自己 没有 问题 ， 那 用 户 该 怎么 办 ? 最 后 只 好 抓 了 个 
包 ， 上 传 到 我 们 的 工具 上 分 析 。 图 1 就 是 该 工具 的 首页 ， 它 的 全 称 为 
Network Performance Analyzer， 和 人 简称 NPA。 用 户 唯 一 需要 做 的 就 是 把 网 
络 包 拖 进 方 枉 ， 然 后 点 一 下 Upload 按 钮 。 
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图 1 
几 秒 钟 后 ， 分 析 报 告 就 出 来 了 。 从 上 往 下 Es 是 “概况 分 析 ”、“ 应 
用 层 分 析 ”、“ 传 输 层 分 析 ” 等 ， ee 
图 2 显示 的 是 “概况 分 析 ”， 目 的 是 给 用 户 呈 现 一 个 直观 的 性 能 
况 。 比 如 “Data bytes rate: 22 kBps” 和 “Capture duration: 900 seconds”， 
表明 在 抓 包 的 900 秒 里 ， 平 均 性 能 才 22KB/s， 实 在 是 很 差 。 流 量 图 的 柱 
体高 度 起 伏 不 大 ， 说 明 这 上 段 时 间 内 传输 均匀 ， 没 有 爆发 性 的 流量 或 者 暂 


集 。 
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Summary 

Number of packets 581 

File size 22 MB 
Capture duration 900 seconds 
Data byte rate 22 kBps 
Average packet size 346.54 bytes 


Connection 102.200.164.30:50727 <-> 102.200.164.10:2049 


Flow Analysis 


Flow Analysis 











接 下 来 是 “应 用 层 分 析 ”， 有 具体 可 见 图 3。 该 工具 自动 判断 出 这 个 包 
的 应 用 层 协议 是 NFSv3， 因 此 把 NFS 啊 应 时 间 (Service Response Time， 
SRT) 和 IO ”Size 统 计 了 出 来 。 从 图 中 的 第 一 个 方 框 可 见 READ 的 平均 响 
应 时 间 是 0.226 毫 秒 ， 算 非常 好 了 。 可 是 从 第 二 个 方 框 却 看 到 每 次 读 的 
数据 量 只 有 975 字 节 ， 还 不 到 1KB， 实 在 是 太 小 了 。 这 就 像 用 货车 从 北 
京 往 上 海运 1000 个 包 里 ， 假 如 每 次 能 运 100 个 ， 那 10 个 来 回 时 间 就 搞定 
了 。 而 假如 每 次 只 能 运 1 个 ， 就 得 跑 1000 个 来 回 ， 那 浪费 在 路 上 的 时 间 
束 非 常 可 观 了 。 因 此 ， 这 个 案例 的 解决 方式 就 是 调整 软件 的 IO Size， 增 
大 到 每 次 读 64K 字 节 ， 人 性 能 立即 得 到 大 幅度 提升 。 你 可 能 会 好 奇 ， 为 什 
么 同样 的 IO Size， 处 理 本 地 硬盘 上 的 数据 就 没有 性 能 问题 呢 ? 这 就 是 网 
络 的 弱点 了 ，TCP/ 耻 几 层 处 理 下 来 ， 总 会 增加 一 些 延 迟 的 。 当 来 回 次 数 
特别 多 的 时 候 ， 延 迟 的 效应 就 被 放大 了 。 
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NFSv3 SRT 


Procedure calls Min SRT (s) Max SRT (s) Avg SRT (s) Total (s) 
GETATTR 3654 0.000000 0.003907 0.000012 0.042969 
LOOKUP 6494 0.000000 0.003907 0.000019 0.121093 
ACCESS 8622 0.000000 0.023437 0.000013 0.109372 

0.000000 0.019531 0.000226 1.941406 
WRITE 5 0.000000 0.000000 0.000000 0.000000 
CREATE 5 0.000000 0.003906 0.000781 0.011718 
REMOVE 0.000000 0.003906 0.000434 0.003906 
RENAME 9 0.000000 0.003906 0.000617 0.011718 
READDIR 8 0.000000 0.000000 0.000000 0.000000 
READDIRPLUS 6 0.000000 0.000000 0.000000 0.000000 
FSSTAT 0.000000 0.000000 0.000000 0.000000 


COMMIT 5 0.000000 0.003906 0.000260 0.003906 


NFSVv3 IO Size 


There were 8584 read operations with average size 975 byteshnd 15 write operations With average size 








图 3 
既然 在 应 用 层 惑 已 经 找到 症结 ， 我 们 也 没 必要 再 去 看 传输 层 了 。 不 
过 传输 层 可 是 性 能 问题 的 高 发 区 ， 也 是 这 个 工具 的 特长 之 处 ， 所 以 我 忍 
不 住 再 给 大 家 看 两 个 案例 。 
图 4 是 VMware 性 能 兰 的 案例 。 抓 包 分 析 后 ， 发 现 总 共 250 秒 的 抓 包 
时 间 里 ， 有 190.8 秒 和 伞 浪 费 在 延迟 确认 上 了 ， 用 上 这 工具 之 后 简直 就 是 
秒杀 。 由 于 本 书 是 黑白 印刷 的 ， 所 以 看 不 出 该 工具 已 经 把 出 问题 的 提示 








文本 设置 成 红色 背景 ， 实 际 上 是 非常 醒目 的 。 
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Delayed ACK 


Among the 2057 pure ACKS SG SRL :pA :mA el 


be Delayed ACKs 





Each Delayed ACK takes about 0.2 second, which means 190.8 seconds have been wasted in this 
connection. You may disable Delayed ACK if the impact is high 





图 4 
图 5 则 是 我 上 一 本 书 的 《 深 茂 功 与 名 》 文 章 中 提 到 过 的 茶 银 行 案 
例 ， 根 本 原因 是 网 络 拥塞 导致 的 丢 包 ， 而 且 SACK 也 没有 启用， 两 个 根 
源 都 被 这 工具 分 析出 来 了 。 当 时 要 是 用 上 这 工具 ， 也 是 很 快 就 能 解决 
的 。 


际 
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TCP Retrans 
Among the 91379 packets, WB EAI A: 901 of them Were 


retransmitted from 10.70.16.10 to 10.72.15.10 , and 0 of them were retransmitted from 10.72.15.10 to 
10.70.16.10 . 








The Retransmission rate over 0.1% indicates a network congestion, and 0.01% ~ 0.1% is questionable. If 
this retransmission rate is considered as high for your product, please work with network team to figure 
out the cause. Limiting the TCP window or extending the bandwidth could reduce retransmission 


TCP SACK 


SACK was not enabled in this TCP session, please check both sides to enable SACK. Enabling SACK 
could reduce the impact of retransmission 








图 5 
我 手头 的 案例 还 有 很 多 很 多 ， 篇 幅 所 限 就 不 一 一 列举 了 。 可 以 说 ， 
我 司 的 大 多 数 网 络 性 能 问题 都 可 以 用 这 个 工具 找到 症结 。 有 很 多 团队 已 





经 从 中 受益 ， 因 为 他 们 不 用 再 请 林 沛 满 吃饭 看 包 了 ， 自 助 就 能 完成 。 我 
当然 也 很 高 兴 ， 因 为 得 以 摆脱 耗 时 的 重复 性 劳动 ， 有 了 更 多 的 时 间 可 以 
带 娃 。 看 到 这 里 ， 不 知道 你 是 否 也 想 打 造 一 个 适合 自己 职业 的 分 析 工 具 
呢 ? 有 兴趣 的 话 可 以 参考 我 的 开发 过 程 ， 大 致 可 以 分 为 三 步 。 

第 一 步 : 收集 旧 问 题 。 

我 们 不 可 能 开发 一 僚 具 有 人 工 智 能 的 程序 来 分 析 网 络 包 。 换 名 话 
说 ， 自 己 打 造 的 工具 本 质 上 不 会 比 Wireshark 更 聪明 。 不 过 我 们 可 以 把 自 
己 的 工作 经 验 “ 传 授 ” 给 这 个 程序 ， 使 它 看 上 去 比 Wireshark 智 能 很 多 。 要 
如 何 做 到 呢 ? 世界 上 绝 大 多 数 故 障 都 不 是 第 一 次 发 生 的 ， 有 经 验 的 工程 
师 可 以 把 处 理 过 的 旧 问 题 收 集 起 来 ， 归 纳 出 每 个 问题 在 网 络 包 中 各 有 什 
么 特征 。 以 后 抓 到 新 的 包 ， 就 可 以 用 这 些 已 知 特征 逐个 去 套 ， 一 旦 发 现 
匹配 得 上 的 就 提示 用 户 。 比 如 我 已 知 有 20 个 原因 会 影响 网 络 性 能 ， 每 个 
原因 在 网 络 包 中 都 会 有 一 些 特征 ， 就 可 以 在 新 抓 的 网 络 包 里 用 这 20 个 特 
征 去 逐个 匹配 。 一 旦 发 现 有 符合 的 就 提醒 用 户 ， 就 像 图 4 和 图 5 那样 。 

Wireshark 需 要 用 户 点 击 多 个 按钮 才 会 去 分 机 ， 但 我 们 的 工具 会 主动 
分 析 并 生成 报告 ， 这 对 用 户 来 说 就 是 智能 化 的 体验 。 不 只 是 网 络 性 能 问 
题 ， 任 何 网 络 相 关 的 技术 领域 都 可 以 采用 这 个 方法 ， 比 如 从 事 Windows 
Domain 相 关 工 作 的 技术 人 员 ， 可 能 保存 着 上 百 个 常用 的 微软 KB， 其 中 
包括 DNS 解析 出 错 、Authenticator 过 大 、UDP 包 被 切 分 丢弃 ， 等 等 。 这 
些 问题 都 可 以 在 网 络 包 中 以 某 个 特征 体现 出 来 ， 因 此 也 可 以 写成 程序 去 
匹配 。 网 管 员 做 监控 也 是 如 此 ， 很 多 场景 都 是 固定 的 。 

把 这 些 旧 问题 收集 好 了 ， 就 已 经 同 成 功 迈 出 一 大 步 。 不 过 实际 做 起 
来 可 没 那么 轻松 ， 你 也 许 需 要 召集 团队 中 最 有 经 验 的 工程 师 ， 收 集 他 们 
的 需求 和 抓 过 的 网 络 包 ， 然 后 再 筛选 和 测试 。 在 这 一 步 收 集 到 的 旧 问 题 
有 多 全 面 ， 就 决定 了 你 做 出 来 的 工具 有 多 强大 。 

第 二 步 : 用 tshark 来 做 匹配 。 

tshark 是 Wireshark 的 命令 行 形式 ， 适 合 被 其 它 程序 调用 来 分 析 网 络 
































包 ; 再 加 上 其 分 析 结 果 是 文本 输出 的 ， 所 以 作 二 次 加 工 也 很 方便 。 基 于 
这 两 点 ， 选 用 tshark 来 匹配 已 知 的 特征 是 最 合适 的 ， 如 有 果 你 已 经 在 上 一 
步 整理 出 了 20 个 特征 ， 那 么 再 编辑 20 条 tshark 命 令 就 基本 可 
tshark 命 令 的 使 用 方法 在 上 一 本 书 中 已 经 介绍 过 ， 这 里 就 不 重复 了 。 

单 举 个 的 例子 ， 己 知性 能 问题 的 特征 之 一 是 TCP 重 传 ， 0 
令 就 可 以 匹配 了 : 


tshark-n-q-r<file_name>-z io，stat,，0， 





tcp.analysis.retransmission, “tcp.analysis.retransmission and ip.src== 
<IP_A>”, “tcp.analysis.retransmission and ip.src==<IP_B>” 
输出 示例 如 下 : 


二 
吧 Command Prompt 





i 





:NUsers\1linpl\DesktopNStarIIN\SampJles>tshark -n 1g 了 ,Sample_filter. cap 
tcp.analysis.retransmission and ip.src== 10.72.15. 


! IO Statistics 
重 


! Duration: 56.5 secs 
! Interval: 56.5 secs 


! Col 1: tcp.analysis.retransmission 
| 2: tcp.analysis.retransmission -?0.16.10 
: tcp-.analysis.retransmission = yg en re i | 


. . 13 
! Frames |! Bytes ! Frames ! Butes ! Frames ! Butes 


:NUsersNlinplN\DesktopNStakrIIN\Samples>。 


« MM 








图 6 
在 图 6 的 输出 中 ， 列 1 的 Frames 表 示 所 有 重 传 包 数 ， 列 2 表示 从 IP_A 
到 IP_B 的 重 传 包 数 ， 列 3 表示 从 IP_B 到 IP_A 的 重 传 包 数 。 有 了 这 些 值 就 
很 容易 统计 重 传 率 和 重 传 方向 。 
当 你 不 知道 某 个 特征 所 对 应 的 tshark 命 令 是 什么 的 时 候 ， 可 以 尝试 
从 Wireshark 中 把 它 找 出 来 ， 然 后 右键 点 击 该 特征 ， 选 择 “Prepare a 
filter” “Selected”， 就 可 以 在 过 滤 栏 生成 表达 式 了 ， 如 图 7 所 示 。 有 了 这 





个 表达 式 就 很 容易 应 用 到 tshark 命 令 中 。 


Filter | tcp.analysis.fast_retransmission 


[>| Expression... Clear Apply Save 


No. Time Source Destination Protocol Info 
166 0.102757000 Client server TCP [TCP Fast Retransmission] [TCP segment of a re: 
167 0.102771000 server Client TCP 3260-61965 [ACK] Seq=145 Ack=58401 Win=1024 Lel 
Client Server TCP [TCP seqment of a reassembled PDU] 


168 0.102778000 





了 


习 [Expert Info (Note/sequence): This frame is a (suspected) fast retransmission] 
[This frame is a (5uspected) fast ret 
[severity level: Note] 









Expand Subtrees 


[Group: sequence] | 


习 [Expert Info (Note/sequence): This fram 
TCP Segment data (1460 bytes) 


00 60 16 36 10 44 00 2a 6ab9b041080| 
05 dc a8 51 40 00 7e 06 1b 29 0a 46 10 0| 


Collapse Subtrees 
Expand All 
Collapse All 


Apply as Column 





0020 of oaf2 0d Oc bc 78 d9 55 bd f8 45 45 2] : R 

0030 80 00 02 b3 00 00 43 6f 6d 62 69 6e 65 6/! APplyas Filter 

0040 72 6f 64 75 63 74 20 61 6e 64 20 43 6f 6| 「 Preparea Filter » Selected 
nnsn Rh1 Ff3 74 2n0 Sa3 7S fFf7 S4 Ff 74 Ff1 Fr 77 7 





图 7 

还 有 些 命令 是 不 能 用 这 个 方法 找到 的 ， 只 能 目 己 碍 tshark 的 官方 文 
档 了 ， 链 接 为 http://www.wireshark.org/docs/man-pages/tshark.html。 
tshark 命 令 真 的 非常 强大 ， 如 果 用 得 好 ， 可 以 实现 很 多 专业 软件 特有 的 
功能 。 

这 一 步 的 tshark 命 令 写 得 有 多 精确 ， 就 决定 了 你 开发 出 来 的 工具 有 
多 可 靠 。 

第 三 步 : 程序 化 。 

到 这 一 步 ， 你 已 经 整理 了 很 多 常见 的 问题 ， 并 知道 如 何 用 tshark 命 
令 来 匹配 它们 ， 是 时 候 写 个 程序 来 完成 整 项 工作 了 。 比 如 说 ， 上 一 步 从 
tshark 输 出 中 得 到 了 重 传 的 包 数 ， 那 就 可 以 用 程序 来 计算 重 传 率 ， 并 决 
定 是 侣 应 该 通知 用 户 。 这 个 程序 可 得 好 好 设计 ， 因 为 它 关 系 到 运行 效率 
( 当 你 抓 到 的 网 络 包 非常 大 时 ， 束 会 发 现 运 行 效率 是 极其 重要 的 ， 盏 则 
等 半 个 小 时 都 没有 结果 ) 。 举 个 例子 ， 应 用 层 上 有 HTTP、FTP、 
iSCSI、NFS、CIFS 等 协议 ， 每 一 个 协议 都 有 不 同 的 问题 ， 每 个 问题 又 
对 应 着 不 同 的 tshark 命 令 。 我 们 总 不 能 拿 到 一 个 网 络 包 ， 就 把 所 有 tshark 
命令 都 运行 一 次 吧 ? 那样 效率 太 低 了 。 正 确 的 方法 是 让 程序 先 判断 包 里 
的 应 用 层 协 议 是 什么 ， 然 后 再 调用 其 相关 的 命令 。 那 怎样 知道 抓 到 的 包 














全 什么 协议 的 电 ? 我 们 可 以 根据 器 口号 来 判断 ， 比 如 端口 号 为 80 时 ， 就 
调用 HTTP 相 关 的 命令 ， 端 口号 为 445 时 ， 就 调用 CIFS 相 关 命令 .…… 还 有 
些 实在 无 法 用 程序 自动 判断 的 ， 可 以 由 用 户 来 辅助 完成 。 比 如 在 页 面 上 
提供 多 个 按钮 ， 对 应 着 不 同 的 协议 ， 让 用 户 自 己 选择 。 总 而 言 之 ， 产 品 
经 理 必须 非常 熟悉 业务 流程 ， 才 能 把 这 个 程序 写 得 高 效 、 科 学 、 友 好 。 

那 用 什么 语言 来 号 这 个 程序 最 好 ? 这 个 没有 定 法 。 我 们 早期 是 用 
Perl 写 的 命令 行 脚本 ， 开 发 简单 ， 运 行 速度 也 快 。 但 它 也 有 致命 的 缺 
点 ， 就 是 界面 不 美观 ， 推 广 和 升级 也 很 麻烦 。 后 来 我 们 改 用 
Python+Flask 做 成 了 Web 的 形式 ， 还 请 专业 美工 人 士 设 计 了 界面 ， 效 果 
就 好 多 了 。 作 为 一 个 有 强迫 症 的 伪 产 品 经 理 ， 我 还 想 强调 细节 的 重要 
性 ， 比 如 网 络 包 分 析 过 程 中 ， 一 定 要 在 页 面 上 显示 一 个 转动 的 菊花 来 延 
长 用 户 的 耐心 ， 见 图 8。 不 要 小 看 这 种 小 细节 ， 如 果 分 析 时 间 超 过 三 分 
钟 ， 又 没有 菊花 在 转动 ， 用 户 很 可 能 以 为 程序 已 经 死 了 ， 然 后 束 点 刷 
新 ， 又 得 从 头 再 来 一 次 。 对 细节 的 重视 程度 ， 很 大 程度 上 决定 了 这 个 工 
具 的 用 户 体验 。 
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图 8 

这 个 工具 就 介绍 这 么 多 ， 和 希望 对 你 有 参考 价值 。 如 果 你 在 开发 过 程 
中 遇 到 什么 问题 ， 也 欢迎 进一步 交流 。 困 难 肯定 会 有 的 ， 但 只 要 肯 动 手 
去 做 ， 你 就 成 功 了 一 半 。 


ned et | es 


现在 是 2015 年 初秋 ， 一 个 收获 的 季节 ， 这 本 书 也 写 到 了 尾声 。 此 刻 
我 正在 小 区 附近 的 咖啡 馆 里 ， 贡 酌 最 后 一 篇 应 该 写 些 什么 。 此 书 的 很 多 
章节 就 是 在 这 家 店 里 完成 的 ， 但 接 下 来 应 该 有 很 长 时 间 不 会 再 来 了 ， 因 
为 最 近 兴 起 的 创业 大 军 实在 太 吵 。 邻 桌 正在 激情 涪 汶 地 讨论 “ 僵 利 模 
式 ”“ 估 值 ”“ 收 购 ”“A 轮 B 轮 C 轮 ”..…. 上 周 还 听 到 一 位 从 阿里 离职 的 
工程 师 在 从 思 同 伴 出 来 一 起 开发 手机 APP， 展 望 前 景 的 语气 让 我 想起 了 
安利 的 培训 。 

其 实 我 六 七 年 前 也 产生 过 一 个 稍 纵 即 逝 的 创业 念头 。 与 现在 流行 的 
P2P、O20 等 概念 不 同 ， 那 时 的 开创 业主 要 集中 在 传统 的 技术 领域 ， 比 
如 我 老板 做 的 数据 迁移 设备 就 卖 了 一 个 很 好 的 价钱 。 有 趣 的 是 那 产 品 两 
年 后 就 被 淘汰 了 ， 命 运 跟 现 在 的 初创 公司 很 像 。 而 我 当时 想 做 的 是 一 个 
网 络 加速 器 ， 它 究竟 是 个 什么 东西 呢 ? 细 想 起 来 ， 它 跟 我 之 前 讲 过 的 很 
多 技术 都 有 关联 ， 不 如 最 后 一 篇 就 写 写 它 吧 ， 束 当 作 知识 总 结 。 

那 几 年 我 接触 了 世界 上 很 多 知名 公司 的 数据 中 心 ， 发 现 他 们 都 有 一 
样 的 痛 点 ， 即 跨 站 点 〈site) 的 网 络 存 在 性 能 瓶颈 。 比 如 图 1 这 样 的 环境 
中 ， 纽 约 的 用 户 访问 伦敦 的 文件 服务 器 ， 或 者 两 边 的 数据 库 做 同步 ， 都 


会 慢 得 出 奇 。 
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图 1 








这 类 问题 排查 下 去 ， 一 般 会 归根 于 带宽 不 足 ， 解 决 方式 就 是 花 钱 购 
买 更 大 的 融 宽 。 然 而 很 少 人 知道 还 有 一 个 不 花 钱 的 办 法 ， 束 是 通过 传输 
层 〈 基 本 者 是 TCP) 的 调 优 来 提高 带宽 利用 率 ， 从 而 提升 性 能 体验 。 那 
时 候 我 已 经 学 会 了 分 析 网 络 包 ， 知 道 传统 的 TCP 协 议 栈 不 能 很 好 地 应 对 
跨 站 点 的 场景 ， 所 以 带宽 利用 率 俩 低 。 有 些 严重 的 甚至 在 50% 以 下 ， 因 
此 存在 很 大 的 提升 空间 。 比 如 客户 从 我 司 购买 的 文件 服务 器 在 路 站 点 时 
访问 不 快 ， 但 经 过 专业 调 优 之 后 ， 性 能 可 以 提升 两 倍 以 上 。 这 就 是 商机 
所 在 : 既然 可 以 通过 调 优 的 方式 来 达到 和 购买 带宽 一 样 的 效果 ， 我 们 就 
有 了 和 僵 利 的 空间 。 接 下 来 的 问题 就 是 怎样 做 成 一 个 产品 了 。 

人 工 调 优 能 做 到 的 事情 ， 理 论 上 程序 也 可 以 做 到 。 因 此 我 最 早 想 做 
的 产品 古 改进 型 的 TCP 协 议 栈 ， 装 在 服务 器 上 ， 使 它 在 路 站 点 场景 中 能 
够 更 乔 能 地 工作 ， 达 到 人 工 调 优 后 的 效果 。 不 过 很 快 就 发 现 这 个 路 子 走 
不 通 ， 原 因 有 三 。 

-有 很 多 操作 系统 不 允许 修改 原 有 的 TCP 协 议 栈 。 比 如 我 司 的 服务 器 
就 是 完全 封闭 的 ， 第 三 方 厂 商 根 本 不 知道 怎么 修改 。 有 些 服务 器 虽然 束 
古 普通 的 Linux 或 者 Windows， 技 术 上 能 够 修改 ， 但 是 厂商 声明 一 旦 动 
了 协议 栈 束 不 再 提供 技术 支持 。 














:即使 服务 器 都 用 上 了 改进 过 的 协议 栈 ， 也 会 受到 客户 端 配置 的 约 
束 ， 难 以 充分 发 挥 。 比 如 在 客户 问 关 闭 了 TCP Timestamps (RFC 
1323) ， 那 在 服务 器 上 计算 RTT 往 返 时 间 〉 时 就 会 受到 影响 ， 或 者 客 
户 病 关闭 了 SACK， 那 在 服务 器 上 局 用 SACK 也 没有 意义 。 

:没有 用 户 愿 意 为 了 改善 跨 数 据 中心 的 访问 ， 而 大 动 干戈 地 对 服务 
器 的 TCP 层 作出 改动 。 万 一 改动 之 后 影响 了 本 地 访问 性 能 怎么 办 ? 

注意 : 这 三 点 只 说 明 该 产品 不 适合 本 文 所 针对 的 场景 ， 而 不 是 说 它 没 有 价值 。 事 实 上 它 在 

有 些 场景 下 可 以 工作 得 很 好 ， 现 在 也 已 经 有 商业 化 的 产品 了 ， 比 如 硅谷 有 家 叫 AppEx Networks 
的 公司 推出 的 单 边 加 速 器 ZetaTCP 就 不 错 。 我 后 来 才 发 现 其 CEO 是 位 华人 ， 在 北京 也 有 分 公 
司 。 市 面 上 还 有 一 些 很 滑稽 的 加 速 嚣 ， 比 如 通过 每 个 包 发 两 次 来 避免 丢 包 的 ， 在 我 看 来 就 是 浪 
费 流量 的 七 伤 养 ， 不 建议 采用 。 
既然 这 个 路 子 完全 走 不 通 ， 我 们 只 能 设计 一 个 不 同 的 产品 了 ， 它 至 
少 要 满足 以 下 需求 才 行 。 

: 它 不 需要 对 服务 器 或 客户 端的 TCP 协 议 栈 作 任何 改动 ， 所 以 实施 的 
障碍 会 小 很 多 。 

它 完 全 独立 工作 ， 所 以 不 受 客 户 端 和 服务 器 上 的 TCP 设 置 所 影 啊 。 
比如 客户 端 上 没有 局 用 SACK 时 ， 它 也 能 处 理 好 连续 丢 包 的 问题 。 

它 只 用 于 改善 路 数据 中 心 的 的 网 络 性 能 ， 对 本 地 访问 时 无 影响 。 

需求 一 旦 明确 ， 解 决 方案 便 呼之欲出 了 。 如 图 2 所 示 ， 只 要 在 两 个 
站 点 的 出 口 各 上 自 染 设 一 台 加 速 器 ， 代 理 两 个 站 点 之 间 的 所 有 TCP 连 接 ， 
就 可 以 满足 以 上 所 有 需求 。 由 于 每 台 加 速 器 与 同 站 点 设备 之 间 的 网 络 状 
况 民 好 ， 所 以 瓶 贷 只 会 沙 在 两 台 加 速 器 之 间 的 网 络 上 ， 我 们 只 需 花 心思 
提升 这 段 网 络 的 性 能 即 可 。 也 许 有 些 读 者 看 到 这 里 会 觉得 好 笑 ， 现 在 这 
种 加 速 器 在 国内 外 至 少 有 十 个 牌子 ， 连 开源 项 目 都 有 了 ， 你 还 创 什么 业 
啊 ? 现在 的 确 是 成 熟 的 市 场 了 ， 但 是 当年 可 完全 不 是 这 样 ， 尤 其 没有 听 
说 过 国内 的 公司 。 我 也 只 是 因为 分 析 了 足够 多 的 网 络 包 ， 便 自然 而 然 地 
萌生 了 引入 加 速 器 的 念头 。 技 术 之 外 的 话题 就 不 多 说 了 。 
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纽约 


图 2 

我 们 先 来 分 析 一 下 这 段 网 络 存在 什么 问题 ， 才 能 对 症 下 药 ， 总 结 下 
来 主要 有 两 个 大 问题 。 

问题 一 : 延迟 高 。 

位 于 同一 站 点 的 两 台 设备 之 间 往 返 时 间 一 般 也 就 儿 毫 秒 ， 而 跨 城 网 
络 的 往返 时 间 可 能 达到 几 十 野 秒 ， 路 国 网 络 其 至 可 达 上 百 曼 秒 。 融 延 到 
为 什么 会 影 啊 性 能 呢 ? 因为 它 会 造成 长 时 间 的 空 等 : 发 完 一 个 窗口 的 数 
据 量 后 ， 发 送 方 就 不 得 不 停 下 来 等 待 接收 方 的 确认 。 延 迟 越 局 ， 发 送 方 
需要 等 待 的 时 间 就 越 长 。 一 图 胜 千言 ， 图 3 演示 了 发 送 窗口 都 是 2 个 
MSS， 延 迟 时 间 分 别 为 10 训 秒 和 20 训 秒 时 的 传输 过 程 ， 可 见 后 者 效率 只 
有 前 者 的 112。 这 好 比 用 同一 辆 货车 运 货 ， 从 上 海运 到 江苏 衣 定 比 从 上 
海运 到 北京 快 得 多 。 

















发 送 窗口 大 小 为 2 个 MSs ”发 送 窗 口 大 小 为 2 个 MSS 








| i 一 
10ms jJ 
Ack 
-< 20ms ] 
Ack 
10ms J ee 
_Ack 一 
10ms ] 
Ack 
20ms ] 
| Ack 
10ms 和 
A | 
客户 端 服务 器 客户 端 服务 器 


图 3 

有 时 候 我 们 会 在 Wireshark 中 看 到 LTCP window Fullj 的 提示 ， 残 
表明 发 送 方 进入 了 等 竺 状态。 这 种 症状 在 跨 站 点 通信 时 是 很 常见 的 ， 具 
体 可 见 本 书 《Wireshark 的 提示 》 一 文中 的 图 9。 那 么 这 个 问题 要 怎么 解 
决 呢 ? 在 延迟 时 间 无 法 减少 的 情况 下 ， 发 送 窗 口 越 大 ， 性 能 惑 越 好 ， 上 所 
以 要 尽 可 能 增 大 窗口 。 

问题 二 : 丢 包 率 高 。 

技 包 一 般 分 两 种 情况 : 一 种 是 网 络 质量 差 导 致 的 零星 丢 包 ; 另 一 种 
是 拥 窄 导致 的 大 量 丢 包 。 跨 站 点 通信 时 这 两 种 丢 包 概率 都 会 增 大 ， 尤 其 
是 后 者 。 这 是 因为 链 路 上 的 情况 比较 复杂 ， 而 且 不 同 的 TCP 连 接 会 “ 恶 
意 ” 地 争夺 本 来 束 有 限 的 带宽 。 比 如 图 2 中 的 文件 服务 器 、 数 据 库 和 邮件 
服务 器 等 建立 的 TCP 连 接 会 各 自 为 政 ， 互 相 和 争夺 珊 宽 ， 直 至 发 生 丢 包 才 
停 下 来 。 这 种 情况 很 像 上 海马 路 上 的 车 辆 ， 为 了 加 速 而 变 道 的 车 多 了 ， 
就 容易 诱发 交通 事故 。 











丢 包 对 性 能 的 影响 极 大 ， 可 以 说 是 网 络 传输 的 第 一 大 忌 ， 有 具体 原因 
我 都 在 上 一 本 书 中 阐述 了 ， 这 里 再 简单 解释 一 下 : 传统 TCP 的 流 控 机 制 
是 一 旦 丢 包 就 认为 发 生 了 拥塞 ， 所 以 发 送 方 会 急剧 地 减 小 友 送 窗口 ， 甚 
至 进入 短暂 的 等 待 状态 〈 即 超时 重 传 》。1% 的 丢 包 率 不 只 是 降低 1% 的 
性 能 ， 而 可 能 是 50% 以 上 。 这 个 问题 有 办 法 缓解 吗 ? 了 也有。 首先 可 以 尽 
可 能 降低 丢 包 的 概率 ， 比 如 提前 预测 并 采取 措施 避免 拥 考 的 有 发生; 其 次 
是 更 精细 地 处 理 丢 包 后 的 流 控 ， 避 人 免 过 度 限 流 。 

一 番 分 析 下 来 ， 发 现 这 两 个 问题 还 是 很 环 手 的 ， 但 是 不 用 担心 ， 我 
们 还 手 握 王牌 呢 一 一 在 加 速 占 上 可 以 大 做 文章 ， 大 幅度 绥 解 这 两 个 问题 
所 带 来 的 影响 。 作 为 一 个 创业 奸商 ， 其 实 我 们 应 该 希望 影响 尽 可 能 ) 
重 ， 和 带宽 利用 紊 最 好 在 50% 以 下 。 因 为 这 意味 着 留 给 加 速 占 的 提升 空间 
就 大 了 ， 客 户 购 买 之 后 能 看 到 明显 的 效果 ， 才 会 觉得 物 有 所 值 。 接 下 来 
要 介绍 的 就 是 缓解 这 两 个 问题 的 措施 ， 也 是 我 们 这 个 加 速 右 的 技术 含量 
所 在 。 

音 施 1: 启用 TCP window scale。 

这 样 可 以 使 最 大 接收 窗口 从 65，535 字 节 ( 老 的 Windows 操 作 系 统 
甚至 只 有 17520 字 节 ) 增加 到 1，073，725，440 字 节 。 发 送 窗口 是 受 接 
收 窗口 和 拥塞 窗口 共同 限制 的 ， 启 用 TCP window scale 之后， 接收 窗口 
就 几乎 限制 不 到 了 ， 当 然 内 存 也 要 跟 得 上 才 行 。 关 于 TCP window scale 
的 更 多 信息 ， 可 参考 本 书 的 另 一 卢 文 章 《 技 术 与 工龄 》。 

音 施 2: 监测 延 玉 来 避免 拥塞 。 

网 络 包 是 以 队列 的 方式 通过 网 络 设 备 的 。 当 拥塞 即将 发 生 时 ， 队 列 
变 长 ， 延 迟 就 会 显著 提高 。 我 做 了 一 个 从 台湾 机 房 往 上 海 机 房 传 数据 的 
实验 ， 一 般 情 况 下 的 往返 时 间 为 74 毫 秒 ( 见 图 4 方 框 中 的 RTT，〉， 而 拥 
窒 丢 包 发 生前 会 逐渐 增加 到 1.69 秒 以 上 。 根 据 这 一 特点 ， 我 们 可 以 让 加 
速 器 在 延迟 明显 增加 时 ， 自 动 放 慢 发 送 速 度 ， 从 而 避免 拥 窄 的 发 生 。 





























一 般 人 情况 : 


Time Protocol info 

3.828125 TCP 8888-60479 [ACK] Seq=553 Ack=435308 Win=4096 Len=0 
3.832031 i Tcp 8888-650479 FEACK] Seqg=553 Ack=437491 Win=4096 Len=D 
3.832031 TP 8888-60479 [ACK] Seq=553 Ack=439674 Win=4096 Len=0 
3.835937 shangha ICP 38338-60479 [ACK] Seq=553 ACKk=441654 Win=4096 Len=0 
3.839843 TP 8888-60479 [ACK] Seq=553 Ack=443836 Win=4096 Len=0 
3.839843 了 CP B888-60479 [ACK] Seq=553 Ack=445616 Win=4096 Len=0 

Ly 





ry 
Window size value: 4096 
[calculated window size: 4096] 
[window size scaling factor: -1 (unknown)] 
四 Checksum: QxSbb8 [validarion disabled] 
Urgent pointer: 0 
田 Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
FT 
is is an ACK 





、 Time hl o 
27323 122.937500 8888-50637 [ACK] Seq=6349 ACK=6085797 Win=4096 Len=0 
27326 122.937500 8888-50637 [ACK] Seq=6349 Ack=6087929 Win=4096 Len=0 
27329 122.941406 8888-50637 [ACK] Seq=6349 ACK=6090705 Win=4096 Len=0 
27332 122.941406 i 8888-50637 [ACK] Seq=6349 Ack=6090725 Win=4096 Len=0 
27334 122.941406 38383-50637 [ACK] Seq=6349 ACcK=6093309 Win=4096 Len=0 
27337 122.941406 8888-50637 [ACK] Seq=6349 Ack=6096075 Win=4096 Len=0 
*| 十 








CODE I TC 


Window Size value: 4096 

[Calculated window size: 4096] 

[window size scaling factor: -1 (unknown)]} 
田 Checksum: Oxif37 [validation disabled] 

Urgent pointer: 0 
田 Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
= [SEQ/ACK analysis! 








这 其 实 就 是 TCP Vegas 的 理念 。 它 用 在 服务 器 上 时 不 见得 很 好 ， 甚 
至 有 负 作 用 。 想 象 一 台 司 用 了 传统 TCP 协 议 栈 的 服务 器 和 一 台 局 用 了 
Vegas 的 服务 器 抢 带 宽 ， 当 拥 寺 即将 出 现时 ， 用 Vegas 的 那 台 监 测 到 了 延 
迟 并 主动 放 慢 速度 ， 从 而 缓解 了 拥塞 ,但 传统 的 那 台 却 得 寸 进 尺 ， 一 直 
激进 地 抢 融 宽 。 最 终结 果 可 能 是 传统 的 那 台 反而 局 了 一 一 劣 币 淘汰 良 
币 。 而 在 加 速 器 上 引入 Vegas 理 念 束 不 一 样 了 ， 由 于 每 个 TCP 连 接 都 是 
一 样 的 算法 ， 所 以 预测 到 拥 紧 时 大 家 可 以 集体 放 缓 ， 从 而 保证 了 公平 
性 。 这 就 像 马路 上 每 位 司机 都 礼貌 廊 让 ， 就 不 会 发 生 事 故 ， 整 条 马路 的 
通行 效率 也 提高 了 。 











除了 能 预测 拥塞 ， 监 测 延 迟 时 间 还 有 助 于 区 分 零星 丢 包 和 拥塞 丢 
包 ， 因 为 发 生 零 星 丢 包 时 的 延迟 一 般 不 变 。 区 分 它们 有 什么 意义 呢 ? 传 
统 TCP 协 议 栈 遇 到 丢 包 都 一 律 当 作 拥 寨 处 理 ， 立 即 放 慢 速度 甚至 暂停 。 
这 样 一 刀 切 并 不 科学 ， 零 星 丢 包 时 重 传 一 下 就 行 了 ， 没 必要 放 慢 速度 。 

音 施 3: 利用 发 送 窗口 实现 优先 级 。 

两 个 站 点 之 间 存 在 很 多 连接 ， 且 优先 级 各 有 不 同 ， 比 如 数据 归档 的 
优先 级 就 可 能 低 于 其 它 应 用 ， 可 以 传 慢 一 点 。 我 们 的 加 速 器 代理 了 两 个 
站 点 之 间 的 所 有 连接 ， 因 此 很 容易 通过 调 市 各 个 连接 的 发 送 窗 口 来 实现 
优先 级 控制 。 优 先 级 低 的 连接 变 慢 了 ， 就 可 以 把 市 宽 让 给 优先 级 高 的 连 
接 ， 用 户 体 验 就 会 更 好 。 

间 施 4: 启用 SACK。 

SACK 即 Selective Acknowledgment， 它 是 处 理 拥 塞 丢 包 时 的 法 宝 ， 
尤其 是 在 高 延迟 的 跨 站 点 环境 中 ， 详 情 可 参考 本 书 的 男 一 片 文章 《来 点 
有 深度 的 》。SACK 必 须 在 发 送 方 和 接收 方 都 启用 ， 这 就是 我 们 在 两 边 
各 架设 一 台 加 速 器 的 优势 。 单 边 TCP 加 速 器 的 效果 很 可 能 因为 另 一 端 没 
有 启用 SACK 而 大 打折 扣 。 

音 施 5: 改进 慢 局 动 算 法 。 

传统 的 TCP 协 议 栈 采用 了 非常 保守 的 慢 局 动 算法 ， 即 把 拥 堆 窗口 的 
初始 值 定 义 得 非常 小 ， 不 能 大 于 4 个 MSS。 而 且 一 旦 发 生 超 时 重 传 ， 又 
要 从 头 进入 慢 启 动 阶段 ， 如 图 5 所 示 。 
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这 就 意味 着 传输 过 程 中 至 少 有 一 段 时 间 的 窗口 极 小 ， 效 率 非 常 低 。 
随 着 便 件 的 更 新 换代 ， 现 在 的 网 络 剖 宽 已 经 今 非 苦 比 了 ， 完 全 没 必 要 如 
此 保守 。 作 为 一 个 专业 的 TCP 加 速 器 ， 我 们 有 必要 在 这 一 点 作出 改进 。 
比如 赋予 发 送 方 一 定 的 “智能 ”使 用 大 一 点 但 仍然 安全 的 初始 值 。 根 据 
我 的 经 验 ， 在 这 一 块 是 很 有 提升 空间 的 ， 因 为 传统 的 TCP 协 议 栈 的 初始 
值 在 现代 网 络 中 显得 实在 太 小 了 。 

音 施 6: 启用 TCPTimestamps。 

在 本 书 的 《一 篇 关于 VMware 的 文章 》 一 文中 ， 已 经 介绍 过 延迟 确 
认 是 如 何 影响 性 能 的 。 不 难 理解 ， 它 也 会 严重 影响 RTT 的 统计 。 我 们 需 
要 精确 地 监测 延迟 时 间 来 预防 拥塞 ， 就 必须 在 两 边 都 启用 TCP 
Timestamps ( 见 RFC ”1323 的 RTTM 一 节 ) 来 排除 延迟 确认 等 因素 的 干 
扰 。 这 也 是 双边 加 速 的 好 处 之 一 ， 在 服务 器 上 单 边 加 速 时 很 难 排除 客户 
端的 干扰 。 








总 结 下 来 ， 这 些 措施 合力 实现 了 这 样 的 效果 : 在 起 步 的 时 候 ， 它 传 
输 得 更 快 ， 在 抢夺 带宽 的 时 候 ， 它 更 懂得 谦让 ; 在 出 现 拥 塞 时 ， 它 恢复 
得 更 迅速 。 此 外 它 还 能 在 一 定 程度 上 避免 拥塞 ， 识 别 零星 丢 包 等 等 ， 
此 流量 可 以 稳定 在 高 位 。 加 速 前 后 的 某 个 TCP 连 接 ， 流 量变 化 大 致 可 以 
用 图 6 来 表示 。 
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加 速 后 流量 图 
图 6 
本 文 提 到 的 这 些 措施 我 大 多 验证 过 ， 由 于 实验 室 中 不 存在 高 延迟 ， 
我 还 搭 了 一 台 专 门 制造 延 埃 和 丢 包 的 路 由 设备 来 仿真 。 其 中 部 分 措施 更 





征 在 用 户 环境 中 验证 过 多 次 。 因 此 可 以 信心 满 满 地 说 ， 这 个 加 速 器 在 技 
术 上 是 完全 可 行 的 。 那 现在 市 面 上 的 加 速 霹 采 用 的 也 是 这 些 撤 术 吗 ? 从 
部 分 公司 所 公布 的 文档 上 ， 我 的 确 看 到 了 一 些 交 集 ， 当 然 它 们 还 用 到 了 
压缩 和 消 重 等 TCP 之 外 的 技术 。Wireshark 在 加 速 器 领域 也 是 大 有 可 为 ， 
这 就 是 为 什么 它 的 主要 捐助 者 是 加 速 占 的 领头 平 Riverbed。 








